Warum Text-to-SQL im Unternehmen scheitert

Das Versprechen ist unwiderstehlich. Jeder im Fachbereich tippt eine Frage in normaler Sprache ein („wie hoch war der Umsatz in Q2 in EMEA?“), und ein Modell macht daraus SQL, führt es aus und liefert die Antwort. Kein Ticket ans Datenteam, kein Warten, kein SQL lernen. Jedes große Warehouse liefert inzwischen eine Fassung davon aus: Snowflake Cortex Analyst, Databricks Genie und Gemini in BigQuery versprechen alle einen Zugang zu Ihren Daten in normaler Sprache.

Und in der Demo läuft es wunderbar. Dann verbinden Sie es mit einem echten Warehouse im Unternehmen, und etwas Beunruhigendes passiert: Die Antworten hören auf, offensichtlich falsch zu sein, und fangen an, unauffällig falsch zu sein. Die Abfrage läuft, eine Zahl kommt zurück, sie wirkt plausibel, doch sie stimmt nicht, weil das Modell abgesprungene Testkonten als aktive Kunden gezählt oder eine Umsatzspalte summiert hat, die bereits um Erstattungen bereinigt war. Der Fehler ist nicht laut. Er ist eine überzeugte, gut formatierte, falsche Antwort, und das ist die gefährlichste Art.

Der erste Reflex ist, das SQL des Modells verantwortlich zu machen. Das ist fast nie das Problem. Das Modell ist ausgezeichnet in SQL-Syntax und schlecht darin zu wissen, was Ihre Daten bedeuten, und im Unternehmen ist die Bedeutung alles.

Der Abstand zwischen Demo und Betrieb ist nicht klein, und er ist inzwischen gemessen. Der Benchmark Spider 2.0, veröffentlicht 2025, hat führende Modelle an realistischen Abläufen für Text-to-SQL im Unternehmen geprüft statt an den kleinen, aufgeräumten Datenbanken früherer Benchmarks. Das Ergebnis war deutlich: Modelle, die auf einfachen akademischen Schemata rund 87 % erreichen, lösten nur etwa 10 % der echten Aufgaben im Unternehmen. Das Problem, das alle für „gelöst“ hielten, war nur für Spielzeugdaten gelöst.

Was hat sich zwischen dem Spielzeug und dem Ernstfall geändert? Größe und Mehrdeutigkeit. Die Enterprise-Schemata in diesem Benchmark hatten im Mittel Hunderte von Spalten, einzelne über dreitausend, dazu stark abgekürzte Namen und das fachliche Wissen, das man zu ihrer Nutzung braucht, verteilt über rund 1,5 Millionen Tokens an Dokumentation. Ein Demo-Schema hat zehn saubere Tabellen, bei denen jeder Spaltenname sich selbst erklärt. Ihr Warehouse hat Tausende von Spalten mit Namen wie amt_net_fx, drei Tabellen, die alle so aussehen, als enthielten sie Aufträge, und eine Regel dazu, was als Umsatz zählt, die nur im Gedächtnis einer Analystin im Finanzbereich existiert.

Selbst Snowflake, dessen eigenes Werkzeug gut abschneidet, sagt es klar: Genaues Text-to-SQL zu bauen ist schwer, sogar für Menschen. Nicht das Modell ist der Engpass. Der fehlende Kontext ist es.

Das ist das große. „Umsatz“ ist keine Spalte, sondern eine Definition. Brutto oder nach Erstattungen? Zählen Geschäfte zwischen Konzerngesellschaften mit? Gebucht oder realisiert? „Aktiver Kunde“ ist noch schlimmer: Jedes Unternehmen zieht die Grenze anders, und die Grenze enthält meist Ausschlüsse (abgesprungene Testkonten, interne Testzugänge, stillgelegte Plätze), die nirgends im Schema stehen. Trifft ein Modell auf die Frage „wie viele aktive Kunden haben wir?“, sieht es eine Tabelle customers und eine Spalte status und trifft eine vernünftige, überzeugte, falsche Annahme.

Genau deshalb stützen sich alle genauen Systeme für Text-to-SQL auf einen Semantic Layer. Snowflake führt die über 90 % Genauigkeit von Cortex Analyst und seine rund 2x höhere Genauigkeit gegenüber LLMs mit einer einzelnen Eingabe auf das semantische Modell zurück (die gepflegte Beschreibung von Kennzahlen, Filtern und Verknüpfungen), nicht auf das Modell selbst. Databricks Genie liest aus demselben Grund die semantischen Metadaten in Metric Views. Was dieses Fehlerbild behebt, ist keine Intelligenz in einem besseren Modell, sondern eine Definition, die das Modell lesen kann.

Selbst wenn das Modell die Kennzahl versteht, muss es die Daten noch finden. In einem echten Warehouse gibt es meist mehrere Anwärter: eine rohe Eingangstabelle, eine Zwischenkopie, eine abgekündigte Alttabelle, die „sicherheitshalber“ stehen blieb, und ein zertifiziertes Mart, dem der Finanzbereich tatsächlich traut. Sie haben ähnliche Namen und sich überschneidende Spalten. Nichts im Schema sagt dem Modell, welche die richtige ist, also nimmt es die, deren Name am wörtlichsten zur Frage passt, und das ist häufig die falsche.

Verknüpfungen erhöhen das Risiko zusätzlich. Den falschen Schlüssel zu wählen, auf der falschen Granularität zu verknüpfen oder eine Eins-zu-viele-Beziehung aufzufächern, verdoppelt unbemerkt Zeilen und bläht jede nachgelagerte Aggregation auf. Die Abfrage ist gültiges SQL, und die Zahl ist falsch. Deshalb sind ein Datenkatalog und Lineage für die Genauigkeit von KI wichtig und nicht nur für die Governance: Sie halten fest, welche Bestände es gibt, welche zertifiziert sind und wie sie zusammenhängen, also genau die Karte, die sich das Modell sonst durch Raten zusammenbauen muss.

Das dritte Fehlerbild macht aus einer falschen Antwort einen echten Vorfall. Ein Werkzeug für Text-to-SQL hat, sich selbst überlassen, keinen Begriff von Verbindlichkeit oder Schutzbedarf. Es weiß nicht, dass das zertifizierte Umsatz-Mart die offizielle Quelle ist und die Spieltabelle einer Analystin nicht. Und es weiß nicht, dass eine Spalte Gehalts-, Gesundheits- oder andere sensible Daten enthält, die dieser bestimmte Nutzer nicht sehen darf.

Also beantwortet es bereitwillig „zeig mir die Vergütung aller“, wenn die Daten erreichbar sind, weil ihm niemand etwas anderes gesagt hat. Genauigkeit und Governance sind hier dasselbe Problem: Das Werkzeug muss wissen, welche Quelle verbindlich ist und welche Daten eingeschränkt sind, und beide Tatsachen stehen in der Klassifizierung und in Richtlinien, nicht im Schema. Ohne diesen Kontext wird aus einem fähigen Assistenten ein schneller, freundlicher Weg, Daten abfließen zu lassen oder inoffizielle Zahlen als Tatsache auszugeben.

Das Muster ist über alle drei Fehlerbilder hinweg dasselbe: Das Modell muss etwas raten, das man ihm hätte sagen sollen. Die Lösung ist daher kein klügeres Modell, sondern aufzuhören, es raten zu lassen. Das heißt, die Bedeutung, die richtigen Quellen und die Regeln in eine geregelte Schicht zu legen, die das Werkzeug liest, bevor es eine Zeile SQL schreibt.

Konkret hat diese Schicht vier Teile. Ein Business Glossary definiert jede Kennzahl und jede Entität einmal verbindlich, mit ihren Grenzfällen, und behebt Fehlerbild 1. Ein Katalog hält fest, was es gibt und welche Bestände zertifiziert sind, und Lineage hält fest, wie sie zusammenhängen und woher sie kommen, was Fehlerbild 2 behebt. Und Klassifizierung samt Zugriffsrichtlinie markiert, was verbindlich und was sensibel ist, was Fehlerbild 3 behebt. Einmal verfasst, von den Menschen, die die Daten verantworten, ist das derselbe Semantic Layer, dessen Wert die warehouse-eigenen Werkzeuge bereits belegen, nur zentral geregelt statt in jedem Werkzeug neu angelegt. Wenn Sie den tieferen Vergleich der Ansätze wollen, lesen Sie RAG und Semantic Layer im Vergleich.

Kontext an einer Stelle zu regeln hilft nur, wenn Ihre KI-Werkzeuge ihn auch lesen können. Wenn jedes Werkzeug sein eigenes privates semantisches Modell behält, sind Sie wieder dabei, „Umsatz“ fünfmal an fünf Stellen zu definieren und zuzusehen, wie die Definitionen auseinanderlaufen. Die Antwort ist ein einziger, offener Auslieferungsweg: das Model Context Protocol (MCP).

Über einen MCP Server werden Ihr Glossar, Ihr Katalog, Ihre Lineage und Ihre Klassifizierung zu einem Endpunkt, den jeder kompatible Assistent oder Agent abfragen kann. Sie regeln die Bedeutung einmal und liefern sie überallhin aus: ein Copilot im Warehouse, ein BI-Assistent und ein eigener Agent greifen alle auf dieselben geregelten Definitionen und dieselben Richtlinien zu. Das nächste KI-Werkzeug, das Sie einführen, wird damit ein weiterer Abnehmer vertrauenswürdigen Kontexts statt einer weiteren Stelle, die auf eigene Faust rät.

Nichts davon spricht gegen warehouse-eigenes Text-to-SQL. Cortex Analyst, Genie und Gemini sind innerhalb ihrer Plattformen wirklich gut, und zwar gerade weil sie darauf gebaut sind, ein semantisches Modell zu nutzen. Die Grenze liegt im Umfang: Jedes regelt Kontext nur für seine eigene Plattform, sodass ein Unternehmen mit mehr als einer Plattform am Ende dieselben Definitionen an mehreren Stellen pflegt, ohne gemeinsame Quelle der Wahrheit und ohne Gewähr, dass sie übereinstimmen.

Diese Lücke füllt Dawiso. Es setzt das geregelte Fundament zusammen, auf das diese Werkzeuge angewiesen sind: einen Data Catalog dessen, was es gibt, ein Business Glossary dessen, was jede Kennzahl bedeutet, Interactive Lineage dessen, woher die Daten kommen, und eine Klassifizierung dessen, was sensibel ist, über mehr als 40 Plattformen hinweg, mit KI-Unterstützung, die Beschreibungen und Klassifizierung zur menschlichen Prüfung vorbereitet. Über den Context Layer und seinen MCP Server liefert Dawiso diese eine geregelte Quelle an jedes MCP-fähige Werkzeug aus, sodass Cortex, Genie, Gemini und Ihre eigenen Agenten ihr SQL gegen dieselbe Bedeutung schreiben. Ein konkretes Paar dazu: wie Snowflake Cortex Agents und Semantic Views von Dawiso geregelt werden. Text-to-SQL bricht nicht, weil das Modell kein SQL schreiben kann. Es bricht, wenn das Modell raten muss, was Ihre Daten bedeuten. Also geben Sie ihm die Antwort, einmal, und regeln Sie sie.