Governed SQL: Warum Text-to-SQL für regulierte Unternehmen neu gedacht werden muss
Von Niklas Hegemann & Sebastian Schorsch · Parlance AI
Unternehmen sitzen auf riesigen Mengen heterogener Daten — Tabellen, Reports, ERP-Exporte, PDFs. Gleichzeitig sind Entscheider von diesen Daten durch technische Barrieren abgeschnitten: Sie können kein SQL, haben keinen Zugang zu BI-Tools oder warten wochenlang auf Ad-hoc-Auswertungen.
Text-to-SQL verspricht die Lösung: natürlichsprachliche Fragen werden automatisch in SQL-Queries übersetzt. „Wie hat sich unser Umsatz nach Produktkategorie in Q4 entwickelt?" — ein Satz, ein Klick, ein präzises Ergebnis. Klingt einfach. Ist es nicht.
Warum klassische RAG-Ansätze scheitern
Die meisten Text-to-SQL-Lösungen am Markt basieren auf klassischem RAG (Retrieval-Augmented Generation): Tabellen werden in Textstücke zerteilt, in einen Vektorindex gepackt und dann vom LLM verarbeitet. Das Problem: Dabei gehen Struktur und Kontext unwiederbringlich verloren.
Ein LLM, das eine Tabelle als Markdown-Chunk verarbeitet, kann keine zuverlässigen SUM()-, AVG()- oder JOIN-Operationen durchführen. Es rät — mit allen Konsequenzen für Genauigkeit und Auditierbarkeit.
| Problem | Beschreibung |
|---|---|
| Strukturverlust | RAG-Systeme linearisieren Tabellen in Fließtext. Zeilen-/Spaltenbeziehungen, Datentypen und Aggregationslogik gehen verloren. |
| Fehlende Globalansicht | Chunking verhindert Aggregationen über ganze Tabellen. Das LLM sieht nie die vollständige Datenbasis. |
| Keine symbolische Exaktheit | LLMs „raten" Zahlen statt sie zu berechnen. Für Finanzkennzahlen ist das inakzeptabel. |
| Keine Nachvollziehbarkeit | Standardmäßige LLM-Antworten liefern keine auditierbare Kette von Datenquelle → Berechnung → Ergebnis. |
| Datensouveränitätsproblem | Cloud-basierte Text-to-SQL-Dienste senden Datenbankmetadaten und Nutzdaten an externe Server. Für regulierte Branchen schlicht nicht akzeptabel. |
Der andere Ansatz: Governed SQL
Parlance verfolgt einen fundamentell anderen Ansatz: Governed SQL. Anstatt Tabellen zu linearisieren, werden sie in ihrer nativen Struktur belassen und via SQL abgefragt. Das Ergebnis ist symbolisch exakt — keine probabilistische Textgenerierung, sondern echte Berechnung.
Das Architekturprinzip in vier Stufen:
- Query Decomposition — Komplexe Fragen werden in SQL-fähige Teilschritte zerlegt. Multi-Hop-Reasoning löst verschachtelte Anfragen in ≤5 Schritten.
- Text Retrieval — Unstrukturierte Dokumente (PDFs, Reports) werden via semantischer Vektorsuche eingebunden und mit SQL-Ergebnissen kreuzvalidiert.
- SQL Execution — Ausschließlich READ-ONLY-Statements gegen die Originaldatenbank. Exakte symbolische Berechnung, kein Raten. Bei Syntaxfehlern bis zu 3 automatische Retry-Versuche.
- Compositional Answer — Ergebnis mit vollständiger Quellenangabe, SQL-Trace und lückenlosem Audit-Log.
Datensouveränität als hartes Kriterium
Der entscheidende Unterschied zu Cloud-basierten Tools: Bei Parlance verlassen weder Metadaten noch Nutzdaten die Infrastruktur des Kunden. Der LLM-Server läuft lokal — on-premises (via Ollama/LM-Studio) oder in einer dedizierten Private Cloud.
Für Banken, FinTechs und Versicherungen ist das keine optionale Komfortfunktion. Es ist regulatorische Grundvoraussetzung. Kein Kreditnehmerdatum, kein Portfolio-Wert, keine interne Kennzahl darf an externe Cloud-Dienste übermittelt werden. Cloud-native Text-to-SQL-Tools können dieses Segment strukturell nicht adressieren. Parlance schon.
DB-Design-Qualität: Der unterschätzte Erfolgsfaktor
Ein Punkt, den die meisten Text-to-SQL-Anbieter verschweigen: Die Qualität der SQL-Generierung hängt massiv von der Qualität des Datenbankdesigns ab. Sprechende Spaltenbezeichnungen, konsistente Namenskonventionen und aussagekräftige Metadaten sind kritische Erfolgsfaktoren — unabhängig vom verwendeten Modell.
Schlechtes Datenbankdesign ist die häufigste Ursache für schlechte Text-to-SQL-Ergebnisse. Deshalb ist unser DB-Design-Check & Data Advisory kein optionales Add-on, sondern integraler Bestandteil jedes Projekts. Wo nötig, empfehlen wir die Einführung einer View-Schicht, die saubere Bezeichnungen und Konventionen für den Agenten bereitstellt.
Selbstlernend durch Nutzung
Jedes erfolgreich ausgeführte SQL-Statement wird mit der ursprünglichen natürlichsprachlichen Frage in einer Vektordatenbank gespeichert. Bei ähnlichen künftigen Anfragen wird dieses „Schema-Gedächtnis" als Few-Shot-Kontext eingesetzt — die Plattform wird mit jeder Nutzung präziser. Dieser selbstlernende Feedback-Loop ist proprieäres IP und wächst mit jedem Kundenprojekt.
Modell-Agnostizität: Kein Vendor Lock-in
Parlance ist backbone-agnostisch: Die Plattform funktioniert mit Claude, GPT, DeepSeek, Qwen und lokalen Open-Source-Modellen. Da sich die Open-Source-Landschaft rasant entwickelt, ist diese Flexibilität keine nette Zusatzfunktion — sie ist strategische Notwendigkeit. Neue, leistungsfähigere Modelle können jederzeit integriert werden, ohne Architekturänderungen.
Wichtige Erkenntnis aus der Praxis: Ein generisches Instruct-LLM kann ein dediziertes SQL-LLM in der Qualität der SQL-Generierung übertreffen — wenn der System-Prompt präzise genug ist. Unsere Prompt Library ist das Know-how-Asset, das den Unterschied macht.
Fazit
Text-to-SQL ist keine reine Technologiefrage mehr. Es ist eine Governance-Frage. Wer die Technologie ernsthaft einsetzen will — besonders in regulierten Branchen — braucht vollständige Kontrolle über den Prozess: von der Frage bis zum SQL-Statement bis zum Ergebnis. Governed SQL ist unsere Antwort darauf.
Wenn Sie mehr erfahren möchten oder ein Pilotprojekt starten wollen, freuen wir uns auf Ihre Nachricht.
