Wer KI-Agenten auf Unternehmensdaten loslässt, bekommt schnell eine nüchterne Lektion in Datenrealität. Tabellen heißen ähnlich, Spalten tragen historische Namen, Kennzahlen haben mehrere Definitionen, und ein Join kann fachlich falsch sein, obwohl er syntaktisch sauber durchläuft. Genau dort entsteht ein Problem, das in vielen Demos kaum sichtbar ist: Der Agent produziert SQL, das plausibel aussieht, aber die falschen Beziehungen zwischen Daten herstellt.
Der Fall Miro beschreibt das Problem recht direkt. Als das Datenteam KI-Agenten unmittelbar auf die Snowflake-Umgebung ansetzte, lagen die Antworten in mehr als 65 Prozent der Fälle falsch. Nicht, weil das Modell kein SQL schreiben konnte. Sondern weil es keine verlässliche Orientierung in einer Umgebung mit mehr als 10.000 Tabellen hatte. Ohne semantische Schicht wusste der Agent nicht, welche Datenbestände zu welchen Geschäftsfragen gehören und welche Verknüpfungen im Alltag tatsächlich verwendet werden.
DataHub setzt an dieser Stelle mit einer sogenannten Context-Intelligence-Schicht an. Der Ansatz: nicht nur Schemas auslesen, sondern vorhandene SQL-Abfragehistorie analysieren, daraus einen semantischen Index bauen und diesen Agenten über Schnittstellen wie MCP, LangChain, Googles Agent Development Kit und CrewAI zugänglich machen. Das klingt zunächst nach einem naheliegenden Schritt. Es ist aber auch ein Eingeständnis: Rohes Metadatenwissen reicht für brauchbare Datenagenten nicht aus.
Das Schema weiß weniger, als es verspricht
In der klassischen Datenbanklogik wirkt ein Schema wie die Landkarte der Organisation. Tabellen, Spalten, Typen, Fremdschlüssel, manchmal Kommentare. Für Maschinen ist das ein sauberer Einstieg. Für geschäftliche Fragen ist es oft zu wenig. Ein Schema erklärt nicht, welche Tabelle für Umsatzberichte wirklich genutzt wird, welche alte Tabelle nur noch aus Kompatibilitätsgründen existiert oder welche Join-Pfade zwar technisch möglich, aber fachlich unsinnig sind.
Gerade in großen Datenlandschaften liegt das relevante Wissen selten an einer einzigen Stelle. Es steckt in Dashboards, in Looker-Modellen, in wiederkehrenden Analystenabfragen, in Notebooks, in internen Konventionen. Manche Beziehungen sind nie formal modelliert worden, werden aber seit Jahren stabil genutzt. Andere Relationen sehen im Schema sauber aus, führen aber in der Auswertung zu doppelten Zählungen oder verzerrten Kennzahlen.
Für einen KI-Agenten ist dieser Unterschied entscheidend. Er kann aus Spaltennamen und Tabellenstrukturen Muster ableiten. Aber er weiß nicht automatisch, welche Muster im Unternehmen gültig sind. Genau daraus entstehen halluzinierte Joins: nicht frei erfundene SQL-Magie, sondern plausible Fehlverknüpfungen in einem System, dessen fachliche Regeln nicht vollständig maschinenlesbar vorliegen.
Query-Logs als Gedächtnis der Datenorganisation
DataHubs These ist deshalb pragmatisch: Die SQL-Historie enthält mehr nutzbaren Kontext als das nackte Schema. Wenn Analysten, Ingenieure und BI-Teams über Jahre hinweg Abfragen geschrieben haben, dann bilden diese Abfragen eine Art operatives Gedächtnis. Sie zeigen, welche Tabellen zusammen verwendet wurden, welche Filter regelmäßig auftauchen, welche Kennzahlen in welchen Zusammenhängen berechnet werden und welche Pfade in der Praxis belastbar waren.
Das ist keine abstrakte Wissensbasis, sondern ein Protokoll tatsächlicher Arbeit. In der Formulierung von DataHub-Mitgründer und CTO Shirshanka Das sollen Unternehmen Jahre von Analystenabfragen in eine abrufbare Wissensbasis verwandeln können, damit Agenten auf Joins zugreifen, die bereits funktioniert haben und von Menschen verwendet wurden. Der entscheidende Punkt ist nicht, dass der Agent mehr Text bekommt. Er bekommt Kontext mit Gebrauchsspuren.
DataHub bringt dafür eine Vorgeschichte mit, die für die Einordnung wichtig ist. Das Projekt entstand ursprünglich bei LinkedIn als Metadatenmanagement-System. Es sollte Daten auffindbar machen und zugleich kontrollieren, dass sie im richtigen Kontext genutzt werden. Das Open-Source-Projekt wurde Anfang 2020 veröffentlicht. Seitdem war Lineage ein zentraler Anwendungsfall: nachvollziehen, wie Daten aus operativen Systemen über Streaming-Infrastruktur in Warehouses und weiter in Geschäftswerkzeuge fließen.
Nach den vorliegenden Angaben zählt das offene Projekt mehr als 15.000 Mitwirkende und rund 3.000 produktive Installationen. In der installierten Basis ist Postgres die am stärksten verbundene Quelle, gefolgt von MySQL, Oracle und großen Cloud-Warehouses wie Snowflake und Google BigQuery. Die Plattform unterstützt mehr als 100 Metadatenquellen. Wichtig ist dabei: Die SQL-Parsing- und Query-Log-Funktionen wurden nicht erst für den aktuellen Agentenfall gebaut, sondern stammen aus jahrelanger Arbeit an Lineage und Metadaten in produktiven Umgebungen.
Der Agent braucht keine Allwissenheit, sondern Grenzen
Die Debatte um Text-to-SQL wird häufig so geführt, als müsse nur das Modell besser werden. Größeres Kontextfenster, besseres Prompting, feinere Instruktionen. Das hilft in Einzelfällen, löst aber nicht das Grundproblem. Ein Unternehmensdatenbestand ist kein Lehrbuchbeispiel. Er ist historisch gewachsen, voller Abkürzungen, Sonderfälle und stiller Vereinbarungen.
Deshalb verschiebt sich die technische Frage. Nicht: Wie bringt man dem Modell SQL bei? Sondern: Wie begrenzt man den Suchraum so, dass es nicht jeden theoretisch möglichen Pfad ausprobiert? Eine Rolle spielen dabei semantische Schichten, Datenkataloge, Lineage-Graphen, Berechtigungen und jetzt stärker auch Query-Historien. Der Agent soll nicht frei durch das Warehouse wandern, sondern entlang bereits bewährter Beziehungen geführt werden.
Das passt zu einer breiteren Bewegung in der Agentenarchitektur. MCP und ähnliche Schnittstellen sollen Werkzeuge, Datenquellen und Kontext systematischer anschließbar machen. LangChain, CrewAI und Googles Agent Development Kit stehen für unterschiedliche Varianten derselben Grundannahme: Ein Agent wird nicht dadurch verlässlich, dass er allein mehr Modellintelligenz bekommt, sondern dadurch, dass sein Zugriff auf Werkzeuge und Wissen kontrolliert strukturiert wird.
Auch alte Abfragen können schlechte Lehrer sein
Der Ansatz hat allerdings Grenzen, die man nicht wegmoderieren sollte. Query-Logs sind nicht automatisch Wahrheit. Sie enthalten Gewohnheiten, Workarounds, veraltete Logik und manchmal schlicht falsche Abfragen. Wenn ein Unternehmen über Jahre hinweg eine fragwürdige Kennzahl reproduziert hat, kann ein Agent diese Praxis stabilisieren statt korrigieren. Historische Nutzung ist ein starkes Signal, aber kein Wahrheitsbeweis.
Hinzu kommt die Frage der Aktualität. Datenmodelle ändern sich, Teams reorganisieren sich, Produkte werden umgebaut, alte Tabellen verlieren ihren Zweck. Ein semantischer Index aus Query-Historie muss deshalb gepflegt, gewichtet und gegen aktuelle Metadaten geprüft werden. Sonst entsteht eine neue Form technischer Trägheit: Der Agent empfiehlt, was früher üblich war, auch wenn die Organisation längst weitergezogen ist.
Auch Berechtigungen bleiben kritisch. Wenn Agenten aus Query-Historien lernen, dürfen sie nicht nebenbei Nutzungsmuster aus Bereichen ableiten, auf die ein Nutzer keinen Zugriff haben sollte. DataHub kommt aus einer Welt, in der Governance und Lineage zentrale Rollen spielen. Gerade deshalb wird sich der praktische Wert solcher Systeme daran messen lassen, ob Kontext, Zugriff und Auditierbarkeit zusammen funktionieren.
Weniger Magie, mehr Datenhygiene
Die interessantere Botschaft liegt nicht in der Produktankündigung selbst, sondern in dem, was sie über den Zustand von Unternehmens-KI verrät. Viele Agentenprojekte scheitern nicht an fehlenden Modellen, sondern an fehlender Datenordnung. Die Systeme werden auf Landschaften angesetzt, die Menschen nur deshalb bedienen können, weil sie informelles Wissen besitzen: Welche Tabelle nimmt man wirklich? Welcher Join ist gefährlich? Welche Kennzahl ist für Finance gültig, welche nur für Produktanalysen?
SQL-Logs sind in diesem Sinne kein eleganter Ausweg, sondern ein realistischer. Sie akzeptieren, dass die operative Wahrheit einer Datenorganisation oft nicht in sauber dokumentierten Modellen steht, sondern in der wiederholten Arbeit erfahrener Teams. Wenn Agenten diese Spuren nutzen, können sie weniger raten. Aber sie übernehmen damit auch die Altlasten der Organisation.
Für Unternehmen ist das eine unbequeme, aber nützliche Diagnose. Wer KI-Agenten auf Daten loslassen will, braucht nicht nur Modellzugang und ein paar Prompts. Er braucht nachvollziehbare Datenbeziehungen, gepflegte Metadaten, kontrollierte Berechtigungen und ein Verfahren, um historische Abfragen von historischem Ballast zu trennen. Der Agent halluziniert den Join nicht im luftleeren Raum. Er stolpert über eine Umgebung, die ihm nicht sagt, welche ihrer vielen möglichen Wahrheiten heute gelten soll.
