Ein Context Layer für Snowflake und Horizon Catalog
Ein Context Layer für Snowflake ist die gesteuerte Schicht fachlicher Bedeutung, also Definitionen, Beziehungen, Lineage und Richtlinien, die aus den Daten in Ihrem Snowflake Account etwas macht, das KI-Agenten verstehen und dem sie trauen können, statt es nur abzufragen. Snowflake selbst hat hier viel investiert, und zwar in den Horizon Catalog, die eingebaute Schicht der Plattform für Governance und Auffindbarkeit, die Snowflake ausdrücklich als „governed context layer for KI, BI, and apps“ positioniert. Zu verstehen, was Horizon leistet und wo ein Context Layer über eine einzelne Plattform hinausreichen muss, ist der Schlüssel dazu, KI im Unternehmen auf Snowflake-Daten zu erden.
Das zählt, weil in Snowflake inzwischen ein großer Teil der Unternehmensdaten liegt und dort über Snowflake Cortex zunehmend auch die KI läuft. Doch auf Snowflake gilt dieselbe Wahrheit wie überall: Ein KI-Modell, das eine Tabelle in Snowflake abfragen kann, weiß deshalb noch nicht, was deren Spalten fachlich bedeuten, ob den Daten zu trauen ist oder wie sie mit Daten anderswo zusammenhängen. Ein Context Layer liefert das, und der nützlichste spannt sich nicht nur über Snowflake, sondern über die ganze Landschaft, auf der das Geschäft tatsächlich läuft.
Ein Context Layer für Snowflake gibt Snowflake-Daten die gesteuerte fachliche Bedeutung, die KI braucht, also Definitionen, Lineage, Beziehungen und Richtlinien. Der eigene Horizon Catalog von Snowflake ist eine starke native Schicht für Kontext und Governance: eingebaute Klassifizierung, Lineage, Überwachung der Datenqualität, Leitplanken für KI und Schutz sensibler Daten, wobei die Governance in der Query-Engine durchgesetzt wird und damit für Menschen, BI und KI-Agenten gleichermaßen gilt. Snowflake vermarktet ihn als „governed context layer“. Die Lücke: Die meisten Unternehmen haben zudem Daten außerhalb von Snowflake und müssen Kontext an jeden KI-Agenten ausliefern, über das offene Model Context Protocol (MCP). Ein plattformübergreifender Context Layer führt Snowflake (samt Horizon) mit der übrigen Landschaft zusammen und öffnet den gesteuerten Kontext für Agenten über MCP.
Ein Context Layer für Snowflake
Innerhalb von Snowflake heißt Context Layer, Ihre Tabellen und Views mit den Metadaten zu umgeben, die ihnen Bedeutung und Vertrauen geben: fachliche Definitionen für jede Kennzahl und jeden Begriff, eine Lineage, die zeigt, wie Daten in jede Tabelle geflossen sind, eine Klassifizierung, die markiert, was sensibel ist, und Richtlinien, die steuern, wer und welcher Agent was nutzen darf. Mit dieser Schicht kann ein KI-Agent, der Snowflake abfragt, die Daten richtig deuten und die Governance achten, statt aus Spaltennamen zu raten und eine selbstbewusste falsche Antwort zu riskieren.
Snowflake hat daraus eine erstklassige Fähigkeit gemacht statt etwas Angebautes, und deshalb muss jede Diskussion über einen Context Layer für Snowflake beim Horizon Catalog beginnen.
Snowflake Horizon Catalog
Der Snowflake Horizon Catalog ist die eingebaute Schicht von Snowflake für Governance und Auffindbarkeit. Sie spannt sich über den Account, mit Fähigkeiten, die sich eng mit dem decken, was ein Context Layer verlangt:
- Automatische Klassifizierung und automatischer Schutz. Horizon entdeckt und klassifiziert Spalten und kann PII und PHI in Ausgaben erkennen, schwärzen und blockieren, auch in den Antworten von KI-Agenten.
- Durchgängige Lineage. Native Lineage, sodass jedes Ergebnis bis zu seiner Quelle zurückverfolgbar ist.
- Überwachung der Datenqualität. Fortlaufende Überwachung, sodass eine Abfrage, ob von einem Menschen oder von einer KI, aktuelle und korrekte Daten zurückbekommt.
- Governance für KI und Agenten. Die Richtlinien werden auf der Ebene der Query-Engine ausgeführt und gelten damit automatisch für jeden Aufrufer, ob Analyst, BI-Werkzeug oder KI-Agent, ohne eigene Konfiguration für die KI.
- Reichweite in offene Formate. Catalog-Linked Databases gleichen die Governance von Horizon mit Objekten in Apache Iceberg ab.
Das ist ein wirklich starkes natives Fundament, mit einer entscheidenden Einschränkung: Es steuert den Perimeter von Snowflake. Alles, was Horizon tut, endet am Rand des Accounts. Genau an dieser Grenze beginnt das Problem im Unternehmen, denn KI-Agenten und die Daten, über die sie schließen, leben fast nie vollständig innerhalb einer einzigen Plattform.
Horizon, Cortex und Kontext
Der Grund, warum Snowflake Horizon zu einem Context Layer ausgebaut hat, heißt Cortex, die Suite an KI-Funktionen samt Cortex Analyst und den Cortex-Agenten, die Fragen in natürlicher Sprache über Snowflake-Daten beantworten. Diese KI-Funktionen sind nur so verlässlich wie der Kontext dahinter, und deshalb zählt gesteuerte Semantik: Semantic Views in Snowflake definieren Kennzahlen und Beziehungen, damit Cortex Analyst aus einfachen Fragen korrektes, gesteuertes SQL macht. Horizon liefert die Governance, die Semantic Views liefern die Bedeutung, und zusammen erden sie die Snowflake-native KI. Das Muster ist genau die These des Context Layer: KI braucht gesteuerte Bedeutung, nicht bloß Daten.
Die Lücke: über Snowflake hinaus
Ein typisches Unternehmen betreibt 15 bis 30 Werkzeuge in seinem Data Stack, und jedes hält ein Stück des Kontextbildes. Weil Horizon nur den Perimeter von Snowflake steuert, öffnen sich vier konkrete Lücken, sobald Ihre Daten und Ihre KI darüber hinausreichen:
- Governance pflanzt sich nicht fort. Eine Klassifizierung oder Richtlinie in Horizon steuert Objekte in Snowflake, sie wandert aber nicht automatisch mit den Daten nach Tableau, Power BI oder Looker. Die Markierung „eingeschränkt“ endet am Rand des Accounts, und die nachgelagerten Werkzeuge verlieren die Governance in dem Moment, in dem die Daten Snowflake verlassen.
- Der fachliche Kontext liegt anderswo. Das Wissen der Organisation, das KI braucht, also Definitionen, Entscheidungen und Vorbehalte, steckt in Glossaren, in Confluence, in Slack und in Team-Wikis, nicht in Snowflake. Ein Katalog, der nur das Warehouse kennt, kann diesen Kontext weder hereinholen noch steuern.
- Plattformübergreifende Lineage bleibt flach. Echte Pipelines laufen von den Quellsystemen über dbt nach Snowflake und weiter in die BI. Native systemübergreifende Lineage ist begrenzt und erfasst nicht den spaltengenauen, transformationsbewussten Pfad über die ganze Kette, also genau das, worauf Folgenabschätzung und Vertrauen in die KI beruhen.
- Widersprüchliche Definitionen und fremde Agenten. Kennzahlen, die in Snowflake, in Databricks und in BI-Werkzeugen definiert sind, driften auseinander; und KI-Agenten, die nicht nativ zu Snowflake gehören, brauchen gesteuerten Kontext über einen offenen Standard, das Model Context Protocol, und keine plattformeigene Schnittstelle.
Das sind keine Mängel von Horizon, sondern die strukturellen Grenzen jedes Katalogs für eine einzelne Plattform. Bleiben sie unadressiert, entstehen Kontextinseln, das Gegenstück der Datensilos, die in den 2000er-Jahren plagten, nur in der Ära der KI: Jedes Werkzeug kennt seinen eigenen Ausschnitt, und niemand, weder Mensch noch KI, sieht das Ganze. Der Wert eines Context Layer liegt genau darin, dass er sich über diese Inseln spannt.
Wie Dawiso dazu passt
Dawiso ist der plattformübergreifende Context Layer, der genau die vier Lücken oben schließt, mit Snowflake als erstklassiger Quelle darin und nicht als Wettbewerber. Es verbindet sich mit Snowflake und über 40 weiteren Plattformen und führt deren Kontext in einer gesteuerten Schicht zusammen, sodass:
- Governance über Plattformen hinweg gilt. Klassifizierung, Verantwortung und Richtlinien liegen an einem Ort und gelten über die ganze Landschaft; sie verdampfen nicht, wenn Daten Snowflake Richtung BI-Werkzeug verlassen.
- Das Wissen der Organisation festgehalten wird. Das Business Glossary definiert jeden Begriff einmal, für Daten aus Snowflake und für alle anderen, und macht aus dem Kontext, der in Wikis und Köpfen gefangen ist, gesteuertes Wissen.
- Lineage durchgängig ist. Die interaktive Data Lineage verfolgt den vollen Pfad von den Quellsystemen über dbt nach Snowflake und weiter in die BI, also die plattformübergreifende Sicht, die ein Katalog für eine einzelne Plattform nicht geben kann.
- Cortex-Agenten in beide Richtungen gesteuert sind. Dawiso liest Snowflake-Cortex-Agenten und ihre Semantic Views in die interaktive Lineage ein, sodass Sie beantworten können, welche Daten dieser KI-Agent tatsächlich sieht, und kann gesteuerte Semantic Views über den herstellerneutralen Standard Open Semantic Interchange (OSI) zurück nach Snowflake erzeugen, womit die Definitionen, die Cortex nutzt, in Dawiso verantwortet und gesteuert bleiben.
- Jeder Agent bedient wird, über offenes MCP. Der Context Layer stellt all das jedem KI-Agenten über den offenen MCP Server zu, also gesteuerten Kontext über Ihre gesamte Landschaft und nicht nur über den Snowflake-Ausschnitt.
Horizon steuert Snowflake weiterhin nativ; Dawiso gibt Ihrer KI den gesteuerten Kontext, den das übrige Geschäft und der übrige Stack tatsächlich verlangen.
Fazit
Ein Context Layer ist das, was Snowflake-Daten in etwas verwandelt, dem KI trauen kann, und Snowflake hat mit dem Horizon Catalog einen starken nativen gebaut: Governance, Lineage, Qualität und Leitplanken für KI, direkt in der Query-Engine durchgesetzt und flankiert von Cortex und den Semantic Views. Für Snowflake-Daten ist das ein mächtiger gesteuerter Context Layer. Was bleibt, ist der Zuschnitt: Unternehmen laufen auf mehr als einer Plattform, und KI-Agenten laufen an mehr als einem Ort. Der vollständige Context Layer führt Snowflake mit der übrigen Landschaft zusammen und stellt jedem Agenten gesteuerten Kontext über offenes MCP zu, damit die KI Ihr ganzes Geschäft versteht und nicht nur den Teil, der in Snowflake liegt.
In Aktion erleben
MCP (Model Context Protocol)
Verbinden Sie Agenten und LLMs direkt mit Ihren Unternehmensdaten und Ihrem Fachwissen.