Ergibt ein eigenständiger Context Layer im Zeitalter der Ontologie von Genie noch Sinn?

Auf dem Data + AI Summit von Databricks am 16. Juni 2026 war die Schlagzeile weder eine schnellere Engine noch ein günstigeres Warehouse. Es war der Kontext. Databricks stellte Genie One vor, einen digitalen Kollegen auf Basis von Agentic AI, der inzwischen allgemein verfügbar ist und echte Ergebnisse liefert (Dokumente, Berichte, Analysen), statt nur Fragen zu beantworten, dazu Genie Agents und ein an Entwicklerinnen und Entwickler gerichtetes Genie Code. Unter all dem liegt die Ankündigung, die für diese Frage am meisten zählt: Genie Ontology, also die Ontologie von Genie.

Databricks hat den gesamten Auftritt um einen einzigen Gedanken gebaut. CEO Ali Ghodsi formulierte es so: Wenn KI einer Finanzchefin nicht sagen kann, warum sich die Margen verändert haben, oder einem Vertriebsleiter nicht den nächsten Zusatzverkauf findet, dann sei das „kein KI-Problem, sondern ein Kontextproblem“. Genie Ontology ist die Antwort von Databricks darauf: Diese Ontologie ist ein in die Plattform eingebauter Context Layer, der Genie in der fachlichen Bedeutung hinter den Daten verankert und darunter von Unity Catalog geregelt wird.

Für alle, die das vergangene Jahr damit zugebracht haben zu argumentieren, dass Enterprise-KI an geregeltem Kontext hängt und nicht am Modell, ist das eine deutliche Bestätigung. Eine der größten Datenplattformen hat gerade ihren eigenen Context Layer gebaut und ihn ins Zentrum ihrer Agentengeschichte gestellt. Das wirft eine berechtigte Frage auf: Wenn Databricks jetzt einen Context Layer ausliefert, ergibt ein eigenständiger dann noch Sinn?

Zunächst die Anerkennung, denn die ehrliche Antwort hängt davon ab, genau zu sein, was Genie Ontology ist. Databricks beschreibt diese Ontologie als „automatischen Context Layer“, der Wissen aus Tabellen, Abfragen, Dashboards, Pipelines und angebundenen Anwendungen zieht und es zu einem „lebenden Graphen davon, wie ein Unternehmen arbeitet“ ordnet. Sie lernt fortlaufend aus Databricks-Daten und über 50 angebundenen Anwendungen und gewichtet Definitionen nach Autorität, damit Genie verlässliche Bedeutung abruft, statt sie jedes Mal neu aus rohen Schemata herzuleiten.

Eine verbreitete Verwechslung lohnt sich hier aufzulösen, weil der Name die Sache nicht ganz trifft. Die Ontologie von Genie ist breiter als ein Semantic Layer und enger als eine formale Ontologie. Ein Semantic Layer übersetzt technische Daten in einheitliche fachliche Definitionen und Kennzahlen; im Databricks-Stack übernimmt das die neuen Metrics in Unity Catalog, die KPIs einmal definieren und einheitlich bereitstellen. Genie Ontology nutzt diesen Semantic Layer und ergänzt Beziehungen zwischen Beständen, Signale aus der tatsächlichen Nutzung und Kontext aus unstrukturierten Anwendungen. Sie verhält sich wie ein gelernter Knowledge Graph und Context Layer, nicht wie eine strenge logische Ontologie. Der Semantic Layer ist also eine Eingabe, die sie speist, und kein Synonym für sie. (Die ausführliche Fassung dieser Unterscheidung steht unter Context Layer und Semantic Layer im Vergleich.)

Genie Ontology wird von einem geregelten Fundament gespeist, das in Unity Catalog modelliert ist: ein Glossary verbindlicher Begriffe (geht in die Vorschau), Domains, die Bestände fachlichen Bereichen zuordnen, und Metrics für geregelte KPIs. Die Architektur ist genau das, was ein Context Layer haben sollte: eine geregelte Quelle der Bedeutung, die eine Schnittstelle speist, über die KI schlussfolgert. Nichts von dem, was folgt, behauptet, dieser Ontologie fehle es an Kontext. Sie hat ihn eindeutig. Die zwei Gründe, aus denen eine eigenständige Schicht trotzdem zählt, betreffen etwas anderes: wer diesen Kontext regelt und wie weit er reicht.

Wenn die Ontologie von Genie ein echter Context Layer ist, kann das Argument für einen eigenständigen nicht lauten, Databricks habe keinen Kontext. Es muss schärfer sein. Zwei Lücken überstehen die Ankündigung, und beide sind struktureller Natur, nicht vorübergehend. Die erste betrifft den Unterschied zwischen Kontext, der erzeugt wird, und Kontext, der geregelt ist. Die zweite betrifft den Unterschied zwischen einer Plattform und der Landschaft, die die meisten Unternehmen tatsächlich betreiben.

Die Stärke von Genie Ontology ist, dass sich diese Ontologie selbst aufbaut. Sie lernt Bedeutung selbsttätig und gewichtet sie nach Autorität, wird also mit der Nutzung besser und braucht kaum Pflege von Hand. Das ist der richtige Entwurf, um einen Agenten schnell zu verankern. Dasselbe wie geregelte fachliche Bedeutung ist es nicht.

Ein selbstlernender Graph optimiert auf das, was in den Daten am meisten genutzt und am glaubwürdigsten ist. Governance optimiert auf etwas anderes: auf eine Definition, für die eine benannte Person verantwortlich ist, die sie prüft und freigibt, die versioniert ist, sodass sichtbar bleibt, was sich wann geändert hat, und für die jemand geradesteht, wenn eine Aufsichtsbehörde oder eine Prüferin fragt. Für die Kennzahl auf einer Vorstandsfolie, die Zahl in einem aufsichtsrechtlichen Bericht oder die Definition von „aktiver Kunde“, an der die Umsatzrealisierung hängt, ist „das Modell hat sie aus der Nutzung abgeleitet“ keine Antwort, die Sie geben wollen. Sie brauchen eine verantwortliche Person und eine Freigabespur.

Databricks liefert die geregelten Eingaben durchaus mit (das Glossary in Unity Catalog wird von Menschen gemeinsam gepflegt, Metrics werden einmal definiert), das Rohmaterial für Governance ist also vorhanden. Doch erst das geregelte Business Glossary macht aus einer Definition einen verantworteten, geprüften Bestand statt eines gelernten Schnipsels, und genau diese Disziplin steht bei einem auf Governance gebauten Context Layer am Anfang. Eine eigenständige Schicht behandelt Verantwortung, Prüfung und Freigabe als Ausgangspunkt, nicht als Nebenprodukt der Nutzung.

Der zweite Grund ist einfacher und für die meisten Unternehmen entscheidend. Die Ontologie von Genie lernt aus Databricks-Daten und aus den daran angebundenen Anwendungen. Das ist der richtige Umfang für den Teil Ihres Unternehmens, der in Databricks liegt. Ihr ganzes Unternehmen ist es nicht.

Eine typische Landschaft betreibt außerdem Snowflake, dbt, BI-Werkzeuge, CRM-Systeme und operative Systeme. Ein einzelner Begriff wie „aktiver Kunde“ und seine Lineage spannen sich meist über mehrere davon: definiert in dbt, materialisiert in einem Warehouse, berichtet in BI, genutzt in einem CRM. Kontext, der in einer Plattform modelliert ist, beschreibt den Teil dieses Wegs, den diese Plattform sehen kann. Der genaueste Agent ist der, der in allem davon verankert ist.

Es gibt auch eine Seite der Auslieferung. Die Ontologie von Genie verankert Genie. Die Copilots, eigenen Agenten und Assistenten, die Ihre Teams auf anderen Stacks bauen, brauchen dieselbe geregelte Bedeutung, ausgeliefert über einen offenen Standard statt gebunden an die Agenten eines Anbieters. Dieser Standard ist das Model Context Protocol (MCP). Ohne eine gemeinsame, geregelte und über MCP bereitgestellte Schicht baut jede Plattform einen ausgezeichneten Context Layer für sich, und das Unternehmen endet mit mehreren unverbundenen: Kontextinseln, die Fassung der Datensilos für das KI-Zeitalter, ein Muster, das wir unter Kontextsilos behandeln.

Nichts davon spricht gegen Genie Ontology. Der praktische Aufbau mit dieser Ontologie ist das Zusammenspiel beider, mit Databricks als vollwertiger Quelle innerhalb einer plattformübergreifenden Schicht statt als Gegenspieler. Dawiso bindet Databricks neben mehr als 40 weiteren Plattformen an und regelt die fachliche Bedeutung, die ein Agent braucht, um über Ihre Plattformen hinweg richtig zu handeln.

Das Business Glossary definiert jeden Begriff einmal, mit einer verantwortlichen Person und einem Freigabeablauf, sodass „aktiver Kunde“ dasselbe bedeutet, ob die Daten in Databricks, in Snowflake oder in einem CRM liegen. Interaktive Data Lineage und Klassifizierung folgen den Daten über Systeme hinweg und ergänzen die native Lineage von Unity Catalog, statt sie zu doppeln. Und die Metadatenschicht für KI stellt diesen geregelten Kontext über den MCP Server jedem MCP-fähigen Agenten bereit, sodass die Bedeutung, auf die sich Genie innerhalb von Databricks stützt, auch den anderen Assistenten im Unternehmen zur Verfügung steht.

Die Arbeitsteilung ist sauber. Unity Catalog und diese Ontologie verankern Genie weiterhin nativ in der Bedeutung aus Databricks. Ein eigenständiger Context Layer macht diese Bedeutung verantwortet, geprüft und über die gesamte Landschaft hinweg einheitlich und stellt sie dann jedem MCP-fähigen Agenten bereit. Das ist der Unterschied zwischen einem Agenten, der Databricks versteht, und einem, der Ihr Geschäft versteht.

Ergibt ein eigenständiger Context Layer im Zeitalter der Ontologie von Genie also noch Sinn? Ja, aus zwei Gründen, die auch nach der Ankündigung bestehen bleiben.

Erstens: Governance ist nicht dasselbe wie Erzeugung. Diese Ontologie erzeugt Kontext selbsttätig und verankert Genie gut, doch geschäftskritische Definitionen brauchen Verantwortung, Prüfung, Versionierung und Rechenschaft, die ein selbstlernender Graph von sich aus nicht liefert. Zweitens: Ihr Geschäft läuft auf mehr als einer Plattform. Kontext und Lineage spannen sich über Snowflake, dbt, BI und operative Systeme, und Ihre Agenten sind nicht alle in Databricks zu Hause, also muss Bedeutung einmal geregelt und über offenes MCP an die gesamte Landschaft ausgeliefert werden.

Genie Ontology ist ein starkes Signal dafür, dass sich die Branche beim Ziel inzwischen einig ist: Der Engpass ist der Kontext, nicht das Modell. Bauen Sie Kontext in Databricks mit dieser Ontologie auf und sorgen Sie dann dafür, dass dieser Kontext verantwortet ist, über die gesamte Landschaft geregelt wird und für jeden MCP-fähigen Agenten erreichbar ist. Genau dafür ist ein eigenständiger Context Layer da.