Natürliche Sprache zu SQL & dialogbasierte Business Intelligence

Die meisten Beschäftigten können kein SQL schreiben, deshalb landet jede neue Frage in der Warteschlange eines kleinen Analytics-Teams. Mit Text-to-SQL und dialogbasierter Business Intelligence (BI) tippt ein Anwender etwa „Umsatz nach Region im letzten Quartal gegenüber Plan“ und erhält eine geprüfte Abfrage, eine Tabelle und ein Diagramm. Der Erfolg hängt weniger vom Modell ab als von einer kontrollierten semantischen Schicht, guten Metadaten und einer Ausführung, die Berechtigungen beachtet.

Problem & Nutzen

• Heute: Dashboards beantworten vordefinierte Fragen; alles Neue wird zum Ticket für das BI-Team. Fachanwender exportieren in Tabellenkalkulationen und erzeugen so uneinheitliche Zahlen („welcher Umsatz?“).
• KI-Nutzen: Selbstbedienung für Ad-hoc-Fragen, schnellere Erkenntnisse, Analysten gewinnen Zeit für Modellierung, und es gibt einen einheitlichen Satz an Kennzahlendefinitionen, wenn Antworten in einer semantischen Schicht verankert sind.
• Realitätscheck: Akademische Benchmarks zeigen eine große Lücke zwischen Demos mit sauberem Schema und echten Unternehmensdatenbanken. Spider 2.0 (Unternehmensabläufe, große Schemata, mehrere Dialekte) wurde entworfen, um diese Lücke sichtbar zu machen, und die Modelle schnitten dort deutlich schlechter ab als im älteren Spider 1.0 [1]; BIRD prüft unsaubere Werte, externes Wissen und Effizienz auf großen Datenbanken [2]. Betrachten Sie Genauigkeitsangaben von Anbietern nur dann als gültig, wenn sie auf Ihrem eigenen Fragensatz beruhen.

Varianten

• Eingebetteter BI-Assistent: Chat innerhalb eines vorhandenen BI-Werkzeugs (Power BI, Tableau, Looker, Qlik).
• Data-Warehouse-nativer Analyst: Assistent innerhalb von Snowflake, Databricks, BigQuery.
• Copilot für Entwickler/Analysten: SQL-Autovervollständigung und -Erklärung in der Entwicklungsumgebung (siehe CODE-022).
• Dialog mit Betriebsdaten: Fragen zu ERP-/CRM-Daten für Vertrieb und Finanzen (FP&A: DATA-024).
• Öffentlicher Sektor / Open Data: Zugang zu Statistikportalen in natürlicher Sprache.
• Private Nutzung: Dialog über Exporte der persönlichen Finanzen oder eine lokale SQLite-Datei; siehe DATA-006.

So funktioniert es

1. Frage
2. Absicht + Entitätsauflösung (Begriffe über das Glossar auf Kennzahlen, Dimensionen, Tabellen abbilden)
3. Kontextabruf (Schema-Teilmenge, Spaltenbeschreibungen, Beispielabfragen, Kennzahlendefinitionen)
4. Erzeugung (Abfrage der semantischen Schicht ODER SQL im Ziel-Dialekt)
5. Validierung (Parsen, Nur-Lese-Prüfung, Positivliste von Tabellen, Kostenschätzung / LIMIT)
6. Ausführung mit den Rechten des *Benutzers* (Sicherheit auf Zeilen-/Spaltenebene)
7. Antwort (Tabelle, Diagramm, Textzusammenfassung + sichtbare Abfrage + Annahmen)
8. Rückmeldung (Daumen, Korrekturen)
9. kuratierter Beispielspeicher

• Schema-Verknüpfung (Schema Linking) ist bei breiten Schemata der schwierige Teil: Nur relevante Tabellen und Spalten mit Embeddings plus Stichwortsuche abrufen und dann ein Reasoning-Modell die Joins planen lassen.
• Zuerst die semantische Schicht: Abfragen gegen kontrollierte Kennzahlen (dbt Semantic Layer / MetricFlow, Cube, LookML, Power-BI-Semantikmodelle) sind deutlich zuverlässiger als rohes SQL auf Rohtabellen und garantieren einheitliche Definitionen.
• Agentische Schleife: Das Modell führt die Abfrage aus, prüft Fehler oder leere Ergebnisse, korrigiert und versucht es erneut.
• Mensch-in-der-Schleife (Human-in-the-Loop): SQL und Annahmen anzeigen; Analysten zertifizieren häufig gestellte Fragen zu „vertrauenswürdigen“ Antworten; folgenreiche Zahlen (Vorstand, Aufsicht) werden nie aus ungeprüftem Chat übernommen.

Datenaufbereitung

Text-to-SQL hängt stärker von Metadaten ab als von der Datenmenge. Die relevanten Daten liegen in der ERP-Datenbank, einem Data Warehouse oder Excel-Dateien auf Dateiservern; das Wissen, was Spalten bedeuten, steckt in den Köpfen der Analysten. Typische Lücken sind kryptische Spaltennamen, undokumentierte Kennzahlendefinitionen (was zählt als „Umsatz“?), Duplikate über Systeme hinweg, fehlende Zugriffsregeln auf Zeilenebene und Tabellenkalkulationen, die als Schattendatenbanken dienen.

Schritte der Aufbereitung: (1) 10–20 echte Geschäftsfragen und die dafür nötigen Tabellen auswählen, siehe PREP-002; (2) Tabellen und Spalten in einfacher Sprache dokumentieren und ein kleines Geschäftsglossar sowie eine Kennzahlenschicht aufbauen, siehe PREP-012 und DATA-007; (3) wichtige Tabellenkalkulationen in saubere Tabellen umbauen, siehe PREP-011 und PREP-003; (4) Dubletten in den Stammdaten mit DATA-003 beheben und die Qualität mit DATA-008 überwachen; (5) Rollen und Berechtigungen auf Zeilenebene festlegen, siehe PREP-023; (6) 30–50 Beispielfragen mit korrektem SQL als Evaluierungssatz sammeln, siehe PREP-018 und PREP-016.

Werkzeuge: dbt oder ein BI-Semantikmodell für Definitionen, eine schreibgeschützte Replik als Abfrageziel, DuckDB für Auszüge aus Tabellenkalkulationen. Grober Aufwandsanteil: etwa 40 bis 50 Prozent des Projekts, überwiegend für Definitionen und Berechtigungen, nicht für Technik. Nutzen Sie vor dem Pilotprojekt den Reifegrad-Check aus GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• smb: Weg A, weil bereits genutzte BI-Plattformen (Power BI, Qlik, Metabase) ausgereifte Dialogfunktionen zu Lizenzpreisen liefern, die sich ein KMU leisten kann.
• enterprise: Weg B, weil semantische Schicht und Zugriffsrechte unternehmensspezifisch sind und die API-Kosten beherrschbar bleiben, während die Kontrolle über die Governance erhalten bleibt.
• developer: Weg C, weil offene Text-to-SQL-Stacks und lokale Modelle volle Kontrolle über Schema, Prompts und Evaluierung erlauben.
• public: Weg C auf souveräner EU-/deutscher Infrastruktur, weil Bürger- und Verwaltungsdaten sowie Vergaberegeln einen Betrieb unter eigener Kontrolle begünstigen.

Weg A — Kaufen (Standardsoftware) (für die meisten Organisationen empfohlen)

• Innerhalb der BI-/Datenplattform: Microsoft Fabric / Power BI Copilot, Tableau (Pulse, Agent), Looker Conversational Analytics (Gemini), Qlik, ThoughtSpot (Spotter), Snowflake Cortex Analyst, Databricks AI/BI Genie, Amazon Q in QuickSight, Domo.
• Spezialisten: Omni, Hex, Julius, Vanna (Open Core), dazu europäische Anbieter wie SAP Analytics Cloud mit Joule (Deutschland), Angebote auf Basis von Mistral und lokale BI-Anbieter (z. B. liefert Pyramid Analytics EU-Hosting; prüfen Sie das konkrete Produkt).
• A wählen, wenn: Sie bereits eine dieser Plattformen betreiben; die Funktion ist eine Lizenzoption und erbt die vorhandene Sicherheit. Prüfen Sie den Datenstandort in der EU und ob Prompts/Ergebnisse die Region verlassen.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Modelle: Spitzen-LLMs mit Werkzeugnutzung und strukturierter Ausgabe (Claude, Gemini, GPT, Mistral Large/Codestral als EU-Anbieter) über EU-Regionen (Azure OpenAI EU Data Zone, Vertex AI EU, Amazon Bedrock Frankfurt/Paris).
• Bausteine: semantische Schicht (dbt MetricFlow, Cube), MCP-Server für Datenbanken und Data Warehouses (damit jeder MCP-fähige Assistent kontrollierte Quellen abfragen kann), Schema-/Metadatenspeicher mit Vektorindex, ein SQL-Parser (sqlglot) zur Validierung, eine Nur-Lese-Rolle je Benutzer.
• B wählen, wenn: Sie eine eigene Benutzeroberfläche, mehrere Quellen oder die Einbettung in ein eigenes Produkt benötigen.

Weg C — Selbst betreiben (Open Source)

• Modelle: Open-Weight-Code-/Reasoning-Modelle, z. B. Qwen3-Coder / Qwen3, DeepSeek, Mistral Codestral, OmniSQL (offene Text-to-SQL-Modelle), bereitgestellt über vLLM oder Ollama.
• Frameworks: Vanna, Wren AI, SQL-Agenten von LangChain/LlamaIndex, Metabase und Apache Superset als BI-Oberflächen, Cube oder dbt Core als semantische Schicht, sqlglot zur Validierung.
• Hardware: HW2 für Modelle der ~30B-Klasse bei überschaubaren Schemata; HW3 für größere Reasoning-Modelle und gleichzeitige Nutzer. Betrieb: Modellbereitstellung, Evaluierungsumgebung, Pflege der Metadaten.

Weg D — Eigenes Training

Ein mittelgroßes offenes Modell mit Ihren eigenen Frage/SQL-Paaren feintunen (Hunderte bis wenige Tausend, aus den Abfrageprotokollen der Analysten), wenn Schema, Dialekt oder Fachjargon ungewöhnlich sind oder wenn Kosten/Latenz ein kleines Modell erfordern. Veröffentlichte offene Text-to-SQL-Modelle zeigen, dass kleine spezialisierte Modelle bei Benchmarks an größere allgemeine Modelle heranreichen können [2]; prüfen Sie dies an Ihren Daten.

Stand der Technik (2026)

• Reasoning-Modelle mit Rückmeldung aus der Ausführung führen die öffentlichen Text-to-SQL-Ranglisten an; Verbesserungen kommen aus Schema-Verknüpfung, Erzeugung von Kandidaten mit Auswahl durch Ausführung und Selbstkorrektur [1][2].
• Verankerung in der semantischen Schicht und MCP sind zum Standardweg zu Genauigkeit auf Unternehmensniveau und einheitlichen Kennzahlen geworden; Anbieter positionieren Agenten, die SQL, Python und Visualisierung kombinieren.
• Grenzen und Fehlerbilder: mehrdeutige Fragen (stillschweigend falsche Interpretation), falsche Joins und Doppelzählung durch Fan-out, falsch angewandte Filter, erfundene Spalten, Eigenheiten der Dialekte, veraltete Metadaten, Fragen, die kausales Schlussfolgern statt Nachschlagen erfordern. Plausible, aber falsche Zahlen sind das Hauptrisiko, weil Anwender Diagrammen vertrauen. Prompt-Injection über Datenwerte in Textspalten ist eine weitere Bedrohung.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (llm-code + embedding-text + vector-db): KNOW-002 RAG-Assistenten, CODE-022 Codegenerierung für Datenpipelines, DATA-006 Assistent für Tabellenkalkulationen.
• Metadaten: DATA-007 Katalog-Anreicherung liefert die Spaltenbeschreibungen, von denen die Genauigkeit abhängt; DATA-008 Datenqualitätsüberwachung markiert unzuverlässige Tabellen.
• Nachgelagert: DATA-002 automatisierte Berichtstexte, DATA-024 FP&A-Copilot.
• Ein LLM-Gateway mit Protokollierung und PII-Schutzmechanismen kann all dies bedienen.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen bis zur Aktivierung; Lizenzaufschlag je Nutzer oder Kapazitätseinheit; der Aufwand fließt in Metadaten und Berechtigungen.
• Weg B: 2–4 Monate für einen kontrollierten Assistenten mit mehreren Quellen und Evaluierungsumgebung.
• Weg C: 3–6 Monate inkl. Bereitstellung und Evaluierung; GPU plus Betriebspersonal.
• Kostentreiber: Rechenzeit im Data Warehouse durch agentisch erzeugte Abfragen (Limits setzen), Pflege der Metadaten, Pflege des Evaluierungssatzes.
• Kennzahlen: Ausführungsgenauigkeit auf Ihrem eigenen Referenzfragensatz, Anteil der Fragen, die ohne Analyst beantwortet werden, Nutzerakzeptanz, Ticketaufkommen beim BI-Team, Abfragekosten je Antwort, Quote korrigierter Antworten.

Menschen & Veränderung

Binden Sie zuerst die Geschäftsleitung und die Abteilungsleitung ein, um einige beantwortbare Fragen auszuwählen und zu akzeptieren, dass Antworten Entwürfe sind, keine Tatsachen. Die Dateneigner und die IT müssen sich auf einen Nur-Lese-Zugriffsweg und auf Definitionen einigen; die IT-Sicherheit prüft die Anbindung und die Anfälligkeit für Prompt-Injection. Endanwender sollten die Fragenliste mitgestalten, weil sie wissen, was sie tatsächlich fragen.

Betriebsrat: abhängig, aber voraussichtlich ja. Das System protokolliert, wer was gefragt hat, und kann Leistungsdaten Einzelner offenlegen (Umsatz pro Person); daher greift § 87 Abs. 1 Nr. 6 BetrVG, wenn ein gewählter Betriebsrat besteht; informieren Sie ihn außerdem nach § 90 Abs. 1 Nr. 3 und erwägen Sie einen Sachverständigen nach § 80 Abs. 3. Öffentliche Stellen beteiligen den Personalrat. Datenschutz: Beziehen Sie die(den) Datenschutzbeauftragte(n) früh ein; eine Datenschutz-Folgenabschätzung (DSFA) ist wahrscheinlich nur nötig, wenn personenbezogene Daten (Personal, Kunden) in großem Umfang abgefragt werden; schließen Sie mit jedem Cloud-Anbieter einen Auftragsverarbeitungsvertrag (AVV) ab.

KI-Kompetenz: Unterstützen Sie die Beschäftigten mit einer kurzen Schulung (was das Werkzeug falsch machen kann, wie man das angezeigte SQL liest), siehe GUIDE-006. Starten Sie mit einer Pilotgruppe von 5–10 Power-Usern und einem KI-Champion, kommunizieren Sie, dass Menschen jede für Entscheidungen verwendete Zahl prüfen, und begegnen Sie der Sorge, Analysten würden ersetzt, indem Sie diese als Verantwortliche für die Definitionen neu positionieren. Weiterführend: GUIDE-004, GUIDE-008, GUIDE-009.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): in der Regel minimales Risiko; Pflicht zur KI-Kompetenz (Art. 4). Fließen Antworten in Entscheidungen über Personen in Anhang-III-Bereichen ein (z. B. Beurteilung von Beschäftigten oder Kreditwürdigkeit), kann die nachgelagerte Nutzung hochriskant sein.
• DSGVO: Data Warehouses enthalten oft personenbezogene Daten; setzen Sie Sicherheit und Maskierung auf Zeilen-/Spaltenebene unter der Identität des fragenden Benutzers durch, nicht über ein Dienstkonto; protokollieren Sie Abfragen (Zweckbindung, Datenminimierung); Auftragsverarbeitungsvertrag und EU-Region für jedes Cloud-Modell; vermeiden Sie es, Rohdatenzeilen an das Modell zu senden, wenn Schema und Aggregate genügen.
• Sicherheit: Nur-Lese-Rollen, Positivlisten für Abfragen, Zeitlimits und Kostenobergrenzen, Schutz gegen Injection, Prüfpfad aus Frage, SQL und Ergebnis.
• Gegenmaßnahmen: SQL und Annahmen anzeigen, zertifizierte Kennzahlen, Regressionstests mit dem Referenzfragensatz bei jeder Modell- oder Schemaänderung, Antworten mit geringer Sicherheit an Analysten eskalieren.

Erste Schritte

1. Wählen Sie einen Bereich (z. B. Vertrieb) und 50–100 echte Fragen mit von Analysten geprüftem SQL als Referenzsatz.
2. Dokumentieren Sie Tabellen und Kennzahlen: Beschreibungen, Synonyme, Join-Pfade; bauen Sie eine kleine semantische Schicht auf.
3. Testen Sie den nativen Assistenten Ihrer aktuellen BI-/Data-Warehouse-Plattform gegen den Referenzsatz.
4. Reicht er nicht aus, bauen Sie einen schlanken Agenten mit Nur-Lese-Zugriff je Benutzer und SQL-Validierung.
5. Rollen Sie ihn für eine Pilotgruppe aus, sammeln Sie Korrekturen und erweitern Sie Bereich für Bereich.

Quellen

1. Spider 2.0 benchmark — https://spider2-sql.github.io/
2. BIRD benchmark (text-to-SQL) — https://bird-bench.github.io/
3. Snowflake — Cortex Analyst documentation — https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst
4. Databricks — AI/BI Genie — https://docs.databricks.com/aws/en/genie/
5. dbt Labs — Semantic Layer / MetricFlow — https://docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sl
6. Vanna (open source text-to-SQL) — https://github.com/vanna-ai/vanna
7. Model Context Protocol — https://modelcontextprotocol.io/
8. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj