Text-to-SQL: KI-Abfragen auf Unternehmensdatenbanken absichern

Datenbankabfragen in natürlicher Sprache, ohne dem Modell die Datenbank zu öffnen? WZ-IT baut KI-Agenten und Assistenten, die freigegebene Daten über eingeschränkte Rollen, Views und geprüfte Abfragen lesen, betrieben auf eigener Infrastruktur. Der KI-Potenzialcheck prüft vorab Prozess, Datenquellen, Rechte und Risiken. KI-Agenten ansehen · Gespräch vereinbaren

Text-to-SQL lässt ein Sprachmodell aus einer Frage wie „Welche Kunden haben im dritten Quartal mehr als 50.000 € umgesetzt?" eine SQL-Abfrage erzeugen und gegen die Datenbank ausführen. Das ist für ERP-, CRM- und Controlling-Daten naheliegend, denn die Antworten liegen dort nicht in Texten, sondern in Tabellen. Die Schwierigkeit liegt an zwei Stellen: Das Modell muss das Schema richtig verstehen, und es darf mit der Datenbank nichts tun, was niemand freigegeben hat. Dieser Artikel erklärt die Architektur, die Rechte in PostgreSQL, die Rolle von MCP-Connectoren und die Messung der Qualität. Stand September 2026.

Inhaltsverzeichnis

• Wie Text-to-SQL funktioniert
• Benchmarks und Praxis: Spider und BIRD
• Die Pipeline: Kontext, Erzeugung, Prüfung, Ausführung
• Datenbankrechte als eigentliche Grenze
• Views als semantische Schicht
• Freies SQL oder vordefinierte Abfragen
• MCP-Datenbank-Connectoren
• Risiken: Prompt Injection, Datenabfluss, Last
• Qualität messen
• Lokales Modell und Betrieb

Wie Text-to-SQL funktioniert

Das Sprachmodell erhält drei Dinge: die Frage, eine Beschreibung der verfügbaren Tabellen und Spalten und Anweisungen zum SQL-Dialekt. Daraus schreibt es eine Abfrage. Die Anwendung führt sie aus und gibt das Ergebnis zurück, als Tabelle oder in einem Satz zusammengefasst.

Der Unterschied zu RAG ist grundsätzlich. RAG sucht Textabschnitte und lässt das Modell daraus formulieren. Bei Text-to-SQL rechnet die Datenbank. Summen, Durchschnitte und Zählungen sind exakt, sofern die Abfrage stimmt. Genau darin liegt das Risiko: Eine falsche Abfrage liefert eine falsche Zahl, die genauso überzeugend aussieht wie eine richtige.

Benchmarks und Praxis: Spider und BIRD

Zwei Benchmarks prägen die Diskussion. Ihre Zahlen zeigen vor allem, wie stark die Ergebnisse vom Schwierigkeitsgrad der Datenbanken abhängen.

Quellen der Bestwerte: BIRD-Leaderboard, Spider-Werte aus dem Spider-2.0-Paper, das o1-preview auf allen drei Benchmarks vergleicht (73,0 % auf BIRD).

Daraus folgen zwei Punkte für die Praxis. Erstens sinkt die Trefferquote deutlich, sobald Schemata groß, unsauber und fachlich aufgeladen sind, also genau so wie in gewachsenen ERP-Systemen. Zweitens sind Benchmarkwerte öffentliche Datensätze, die Modelle beim Training gesehen haben können. Auf dem eigenen Schema entscheidet ein eigener Testsatz, nicht das Leaderboard.

Die Pipeline: Kontext, Erzeugung, Prüfung, Ausführung

Eine belastbare Text-to-SQL-Anwendung besteht aus mehr als einem Prompt. Bewährt hat sich ein Ablauf in fünf Schritten:

Kontext. Ein Modell braucht nicht das ganze Schema, sondern die relevanten Tabellen mit verständlichen Beschreibungen. Spaltenkommentare (COMMENT ON COLUMN) und zwei, drei Beispielabfragen je Themenbereich verbessern die Ergebnisse spürbar. Bei Schemata mit Hunderten Tabellen wird die Auswahl selbst zur Suchaufgabe, ähnlich wie beim Retrieval in RAG.

Prüfung. Die erzeugte Abfrage wird vor der Ausführung geparst, nicht per Textsuche nach „DELETE" durchsucht. SQLGlot (MIT-Lizenz) ist ein Python-Parser für über 30 SQL-Dialekte, darunter PostgreSQL. Mit dem Syntaxbaum lassen sich die Regeln sauber prüfen: genau eine Anweisung, nur SELECT, nur Tabellen und Views aus der Allowlist, ein LIMIT wird ergänzt oder begrenzt. Ein EXPLAIN vor der Ausführung zeigt zusätzlich, ob eine Abfrage absehbar teuer wird.

Ausgabe. Die Anwendung zeigt die ausgeführte Abfrage mit an. Wer die Zahl verwendet, kann so nachvollziehen, welche Filter und Joins dahinterstehen. Das ist der wirksamste Schutz gegen plausibel aussehende Fehlergebnisse.

Datenbankrechte als eigentliche Grenze

Ein Sprachmodell kann jede SQL-Anweisung erzeugen. Prompt-Regeln wie „schreibe nur SELECT" senken die Wahrscheinlichkeit, verhindern aber nichts. Was tatsächlich passiert, entscheiden die Rechte der Datenbankrolle, unter der die Abfrage läuft. Diese Rolle ist deshalb die eigentliche Sicherheitsgrenze, alle anderen Maßnahmen ergänzen sie.

Ein Beispiel für PostgreSQL:

-- Eigenes Schema nur mit freigegebenen Views
CREATE SCHEMA ki;
CREATE ROLE ki_reader LOGIN PASSWORD '...';

GRANT USAGE ON SCHEMA ki TO ki_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA ki TO ki_reader;
-- Keine Rechte auf Basistabellen in anderen Schemata vergeben

-- Komfort-Voreinstellungen, keine Sicherheitsgrenze
ALTER ROLE ki_reader SET default_transaction_read_only = on;
ALTER ROLE ki_reader SET statement_timeout = '15s';

Vier Details sind wichtig:

Wo die Last auf der Produktivdatenbank stört, laufen die Abfragen auf einem Replikat. Verbindungen zu einem Hot Standby sind in PostgreSQL ausschließlich lesend, nicht einmal temporäre Tabellen lassen sich dort schreiben (PostgreSQL, Hot Standby). Für MySQL und MariaDB gilt dasselbe Prinzip mit eigenen Benutzern, die nur SELECT auf freigegebene Views erhalten.

Sollen Nutzer nur ihre eigenen Daten sehen, etwa ein Vertriebsmitarbeiter nur seine Region, gehört diese Einschränkung ebenfalls in die Datenbank: über RLS-Policies oder je Nutzergruppe getrennte Views. Dieselbe Regel beschreibt RAG mit Berechtigungen für Dokumente: Rechte greifen vor dem Modell, nicht in seinem Prompt.

Views als semantische Schicht

Rohtabellen sind für Menschen schon schwer zu lesen, für ein Modell erst recht. Spalten wie stat_cd, kz_storno oder dat_3 erklären sich nicht selbst, und viele Tabellen enthalten Altlasten, Testdaten oder Zwischenstände. Eine semantische Schicht übersetzt das in Begriffe, mit denen Fragen gestellt werden.

In der einfachsten Form sind das Views in einem eigenen Schema:

Größere Installationen nutzen dafür eigene Metrik-Schichten in BI-Werkzeugen. Für den Einstieg reichen Views: Sie sind versionierbar, testbar und begrenzen gleichzeitig, welche Daten überhaupt erreichbar sind.

Freies SQL oder vordefinierte Abfragen

Nicht jede Anwendung braucht freies SQL. Oft ist die Menge der sinnvollen Fragen überschaubar, und dann ist eine Sammlung parametrisierter Abfragen sicherer und genauer.

Bei parametrisierten Abfragen übergibt das Modell nur Werte wie Kundennummer oder Zeitraum. Die Abfrage selbst steht fest und wird mit Platzhaltern ausgeführt, eine SQL-Injection über den Modelltext ist damit ausgeschlossen. Für Agenten, die mehrere Systeme nutzen, ist das ohnehin das übliche Muster: ein Werkzeug je Aufgabe mit klar begrenzten Rechten (KI-Agenten: Rechte und Freigaben).

MCP-Datenbank-Connectoren

Das Model Context Protocol verbindet Assistenten mit Werkzeugen, darunter Datenbanken. Die verfügbaren Server unterscheiden sich erheblich in ihren Schutzmechanismen, Stand September 2026:

Der Fall des Referenzservers zeigt das Grundproblem: Er führte Abfragen in einer Read-only-Transaktion aus, akzeptierte aber mehrere Anweisungen in einem Aufruf. Ein COMMIT; beendete die Transaktion, alles danach lief ohne Schutz. Laut Datadog wurde das Paket bei Veröffentlichung der Analyse im August 2025 noch rund 21.000-mal pro Woche über npm geladen. Die Lehre gilt für jeden Connector: Schutzmechanismen in der Anwendungsschicht ergänzen die Datenbankrechte, sie ersetzen sie nicht.

Risiken: Prompt Injection, Datenabfluss, Last

Die Risiken lassen sich den Kategorien der OWASP Top 10 for LLM Applications 2025 zuordnen:

Wie Prompt Injection über Datenbankinhalte praktisch aussieht, zeigte der Supabase-MCP-Fall vom Juli 2025: Ein präpariertes Support-Ticket forderte den Assistenten auf, die Tabelle mit Integrationstokens auszulesen und den Inhalt in das Ticket zu schreiben. Der Assistent lief mit der service_role, die Row-Level Security umgeht. Simon Willison beschreibt die Kombination aus Zugriff auf private Daten, Kontakt mit nicht vertrauenswürdigen Inhalten und einem Weg nach außen als „lethal trifecta". Fällt eine der drei Zutaten weg, scheitert dieser Angriff. Mehr dazu in Schutz vor Prompt Injection.

Ein verwandtes Muster betrifft Werkzeuge, die aus Ergebnissen Code erzeugen. Bei der Bibliothek Vanna führte Prompt Injection über die Visualisierungsfunktion zur Ausführung beliebigen Python-Codes (CVE-2024-5565, CVSS 8.1). Diagramme werden deshalb aus festen Vorlagen erzeugt, nicht aus modellgeschriebenem Code.

Qualität messen

Eine Abfrage, die ohne Fehler läuft, ist nicht automatisch richtig. Die häufigsten Fehler sind Bedeutungsfehler: Stornos mitgezählt, ein Join verdoppelt Zeilen, das falsche Datumsfeld gefiltert. Gemessen wird deshalb am Ergebnis.

Der Testsatz entsteht mit den Fachleuten, die die Daten kennen: typische Fragen, je eine geprüfte Referenzabfrage, dazu Fragen, die das Schema bewusst nicht beantworten kann. Jede Änderung an Modell, Prompt oder Views wird gegen diesen Satz gemessen. Protokolliert werden Frage, erzeugte Abfrage, Laufzeit und Rückmeldung der Nutzer, etwa mit Langfuse. Das Vorgehen entspricht dem für Retrieval-Systeme in RAG-Qualität messen.

Lokales Modell und Betrieb

Text-to-SQL setzt kein Modell eines Cloud-Anbieters voraus. Gerade bei Unternehmensdatenbanken spricht viel dafür, dass Schema-Beschreibungen, Fragen und Ergebnisse das eigene Netz nicht verlassen. Die Modellwahl hängt von der Komplexität ab: Ein überschaubares Schema mit sauberen Views kommt mit einem mittelgroßen Modell aus, große Schemata mit vielen Joins profitieren von größeren Modellen und längerem Kontext. Welche Modelle selbst betrieben werden können, ordnet Welches LLM selbst hosten? ein, den Speicherbedarf rechnet GPU- und VRAM-Sizing für LLMs durch.

Für den Betrieb hat sich eine klare Trennung bewährt:

Der Text-to-SQL-Dienst hält die Datenbankzugangsdaten, nicht das Modell. Das Modell sieht nur Schema-Kontext und, falls für die Antwort nötig, das Ergebnis.

Was das für Ihr Projekt heißt

Text-to-SQL lohnt sich, wenn viele wiederkehrende Fragen an dieselben Daten gestellt werden und die Antworten heute über Exporte oder Berichtsanfragen laufen. Die Reihenfolge entscheidet über den Erfolg: zuerst eine eigene Rolle und Views mit den freigegebenen Daten, dann ein Testsatz mit Referenzabfragen, erst danach Modell und Prompt. Wo die Fragen überschaubar sind, sind parametrisierte Abfragen genauer als freies SQL.

WZ-IT setzt solche Anwendungen als KI-Agenten auf dem offenen Stack um, mit PostgreSQL oder MySQL als Datenquelle, eingeschränkten Rollen und Tracing. Modelle laufen lokal auf dem AI Cube oder auf Managed GPU-Servern von WZ-IT mit NVIDIA RTX PRO 4000 Blackwell (24 GB) oder RTX PRO 6000 Blackwell Max-Q (96 GB). Support, Beratung und Implementierung durch WZ-IT.

Verwandte Themen: Schutz vor Prompt Injection, MCP im Unternehmen, KI-Agenten & Automatisierung und KI-Agenten-Frameworks im Vergleich.