KI-Agent mit SQL-Datenbankzugriff: text-to-SQL sicher implementieren

Ein Finanzcontroller in einem Vertriebsunternehmen benötigte wöchentlich eine Aufstellung: Umsatz pro Region, Marge pro Produktkategorie, Vergleich zum vorherigen Quartal. Er schrieb diese Abfrage selbst oder wartete auf einen Analysten. Mit der Einführung eines text-to-SQL-Agenten verkürzte sich diese Zeit auf einige Dutzend Sekunden. Nicht, weil das Modell „die Datenbank kennt“. Sondern weil jemand zuvor die richtige Arbeit geleistet hat: das Schema beschrieben, ein Geschäftswörterbuch definiert und Guardrails eingerichtet hat, die sicherstellen, dass der Agent nichts Destruktives tun kann.

Das ist das reale Versprechen von text-to-SQL. Und nicht mehr.

Ein text-to-SQL-Agent ist ein Agent mit Zugriff auf ein Datenbank-Tool. Seine Arbeit sieht wie folgt aus: Der Benutzer stellt eine Frage in natürlicher Sprache, der Agent baut den Kontext auf (Datenbankschema, Geschäftswörterbuch, Beispielwerte aus Spalten), generiert eine SQL-Abfrage, validiert sie vor der Ausführung, sendet sie an die Datenbank, ruft das Ergebnis ab und formuliert eine Antwort zusammen mit der angezeigten Abfrage.

Der entscheidende Bestandteil ist schema-aware Prompting. Bei jeder Frage wird dem Modell eine Beschreibung des Schemas übergeben: Tabellennamen, Spalten, Datentypen, Fremdschlüssel und die Zuordnung von Spalten zu Geschäftstermini. Ohne diese Zuordnung weiß das Modell nicht, dass die Spalte net_rev_adj „angepasster Nettoumsatz“ bedeutet und dass die Werte in Tausend Złoty angegeben sind. Eine falsche Interpretation von Einheiten oder Namen sieht wie ein Modellfehler aus, ist aber ein Konfigurationsfehler.

Der Agent nutzt Tool-Use: Statt eine Abfrage zu generieren und sofort auszuführen, ruft er das Tool sql_query(statement, limit) auf. Dieses Tool hat ein hartes Zeilenlimit (normalerweise 500-2000, abhängig vom Kontext), arbeitet ausschließlich mit einer Read-Only-Verbindung und protokolliert jeden Aufruf mit dem vollständigen Abfragetext und Zeitstempel.

Für komplexe mehrstufige Fragen zerlegt der Agent die Aufgabe in eine Abfragesequenz: Zuerst werden aggregierte Daten abgerufen, dann gefiltert oder verknüpft. Es handelt sich um dieselbe ReAct-Schleife wie beim mehrstufigen Agenten, nur dass das Tool eine SQL-Datenbank statt einer API ist.

Die reine text-to-SQL-Architektur ohne Guardrails ist ein Werkzeug, das Schaden anrichten kann. Im Folgenden beschreibe ich vier Schutzschichten, die wir bei Cashcrown bei jeder Implementierung anwenden.

Schicht 1: Read-Only-Rolle auf Datenbankebene. Die Verbindung des Agenten zur Datenbank verwendet eine Rolle ohne Berechtigungen für INSERT, UPDATE, DELETE oder DROP. Selbst wenn das Modell eine datenmodifizierende Abfrage generiert (z. B. durch Prompt Injection), lehnt die Datenbank sie mit einem Berechtigungsfehler ab. Dies ist die einzige Verteidigungslinie, die unabhängig von allen anderen funktioniert.

Schicht 2: Allowlist für Tabellen und Spalten. Der Agent sieht nur die Tabellen und Spalten, die explizit zugelassen wurden. Tabellen mit personenbezogenen Daten (Namen, E-Mails, Kundennummern), HR-Daten oder finanziell sensiblen Daten sind standardmäßig aus dem Schema ausgeschlossen, das dem Modell bereitgestellt wird. Der Zugriff darauf erfordert eine menschliche Entscheidung, nicht eine Konfigurationsänderung durch den Benutzer.

Schicht 3: Abfragevalidierung vor der Ausführung. Vor jeder Ausführung parst der Guardrail die generierte SQL-Abfrage und prüft: Enthält sie nur SELECT-Anweisungen, bezieht sie sich nicht auf Tabellen außerhalb der Allowlist, liegt das Zeilenlimit unter dem Schwellenwert. Eine Abfrage, die die Validierung nicht besteht, wird protokolliert und eskaliert, nicht an die Datenbank gesendet.

Schicht 4: Human-Gate bei geringer Sicherheit und sensiblen Tabellen. Wenn das Modell die Antwortsicherheit als gering einschätzt (komplexe JOINs, unklare Frage, unbekannte Begriffe), signalisiert der Agent statt einer Antwort: „Menschliche Überprüfung erforderlich“. Dasselbe gilt für jede Abfrage, die als sensibel markierte Tabellen berührt. Human-Oversight ist für diese beiden Klassen keine Option.

Die Präzision von text-to-SQL-Systemen in Produktionsumgebungen variiert zwischen 70 und 85% bei sauberen, gut dokumentierten Schemata. Bei unleserlichen Schemata (Abkürzungen in Spaltennamen, fehlende Fremdschlüssel, uneinheitliche Einheiten) sinkt sie auf 40-60%. Wir bei Cashcrown messen dies vor jeder Produktionsimplementierung mit einem Golden Set von 50-100 Fragen.

Drei Fehlerkategorien treten am häufigsten auf.

Halluzinierte Spalten und Tabellen. Das Modell kann eine Abfrage generieren, die auf eine Spalte verweist, die im Schema nicht existiert, insbesondere wenn das Schema groß oder unvollständig beschrieben ist. Der Guardrail, der SQL vor der Ausführung parst, fängt diesen Fehler ab, bevor er die Datenbank erreicht. Ohne diesen Validator löst die Abfrage einen Datenbankfehler aus, den das Modell möglicherweise nicht korrekt behandelt.

Falsche JOINs bei komplexen Beziehungen. Eine Frage, die das Verbinden von fünf Tabellen über teilweise beschriebene Schlüssel erfordert, führt oft zu einer syntaktisch korrekten, aber semantisch falschen Abfrage. Sie aggregiert auf der falschen Granularitätsebene oder übersieht eine Filterbedingung. Das Ergebnis wirkt glaubwürdig, ist aber falsch. Der Schutz besteht darin, den Agenten zu zwingen, die generierte Abfrage dem Benutzer vor der Antwort anzuzeigen.

Mehrdeutigkeit von Geschäftstermini. „Umsatz“, „Marge“, „Kunde“ können in verschiedenen Abteilungen desselben Unternehmens unterschiedliche Definitionen haben. Das Geschäftswörterbuch in der semantischen Schicht muss diese Begriffe eindeutig auf konkrete Spalten und Formeln abbilden. Fehlt diese Abbildung, ist dies eine Fehlerquelle, die schwer zu erkennen ist, weil die Zahlen sinnvoll aussehen. Details zur Datenaufbereitung für KI beschreibt der Artikel KI für Datenanalyse und BI.

Das ist keine Frage der Konfiguration, die später gelockert werden kann. Das ist eine architektonische Grenze.

Ein text-to-SQL-Agent führt niemals autonom Abfragen wie INSERT, UPDATE, DELETE oder DDL aus. Selbst wenn der Benutzer eine Datenänderung per Konversation anfordert. Selbst wenn der Prompt harmlos aussieht. Die Read-Only-Rolle auf Datenbankebene ist die einzige Verteidigungslinie, die unabhängig vom Modell funktioniert.

Der Agent greift niemals auf Tabellen zu, die PII enthalten (personenbezogene Daten von Kunden, Mitarbeitern, Auftragnehmern), ohne eine explizite menschliche Entscheidung. Diese Tabellen sind aus dem Schema ausgeschlossen, das dem Modell bereitgestellt wird. Der Zugriff darauf ist nur über einen Pfad mit Human-Gate möglich, bei dem der Operator sieht, welche Daten abgerufen werden, und die Abfrage genehmigt oder ablehnt. Die Integration des Agenten mit Unternehmenssystemen wie ERP behandelt der separate Artikel Integration von KI mit ERP und Systemen.

Abfragen mit geringer Modell-Sicherheit (unklares Frage, keine Übereinstimmung mit dem Schema, leeres Ergebnis bei erwartetem nicht-leerem) werden an einen Menschen mit Kontext weitergeleitet: angezeigte Abfrage, Grund für die Eskalation und Vorschlag zur Vereinfachung der Frage. Die Sicherheit von Agenten behandelt ausführlicher der Artikel Sicherheit von KI-Agenten.

Observability eines text-to-SQL-Agenten ist nicht nur Logging um des Loggings willen. Es ist die Grundlage für das Vertrauen in die Ergebnisse und eine Anforderung des AI Act für Systeme, die Geschäftsentscheidungen beeinflussen.

Jeder Aufruf des Datenbank-Tools erzeugt einen Datensatz mit: Benutzerfrage, generierte SQL-Abfrage, Anzahl der zurückgegebenen Zeilen, Ausführungszeit und Ergebnis der Guardrail-Validierung. Diese Datensätze dienen drei Zwecken.

Erstens: Qualitätsmonitoring – welcher Prozentsatz der Abfragen endet erfolgreich, welcher wird eskaliert, welcher führt zu Guardrail-Fehlern. Ein Anstieg der Eskalationsrate ist ein Signal für Drift (Schemaänderung, neue Begriffe in Benutzerfragen ohne Aktualisierung des Wörterbuchs).

Zweitens: Golden-Set-Test – ein Satz von 50-100 Fragen mit erwarteten Ergebnissen, der regelmäßig (einmal pro Woche oder bei jeder Schemaänderung) ausgeführt wird. Ein Präzisionsabfall unter den Schwellenwert warnt, bevor Benutzer Fehler melden.

Drittens: Audit-Trail, wie vom AI Act und RODO für Systeme gefordert, die finanzielle oder personelle Entscheidungen beeinflussen. Jede Antwort muss reproduzierbar sein: Es muss bekannt sein, welche Abfrage das Ergebnis erzeugt hat, aus welchen Daten und zu welchem Zeitpunkt. Die Validierung von Modellausgaben beschreibt detailliert der Artikel Validierung von LLM-Ausgaben.

Beschreiben Sie das Schema Ihrer Datenbank und eine analytische Frage, die Sie stellen möchten, und das Modell entwirft die Architektur eines text-to-SQL-Agenten: Schema-Prompting, Guardrails und Human-Gate-Stellen für Ihren Anwendungsfall (Playground: PII maskiert, keine Speicherung):

Bei einem sauberen, gut dokumentierten Schema mit beschriebenem Geschäftswörterbuch liegt die Präzision ohne zusätzliches Fine-Tuning zwischen 70 und 85%. Bei einem Schema mit mehrdeutigen Spaltennamen, fehlenden Fremdschlüsseln oder gemischten Einheiten sinkt die Präzision auf 40-60% und erfordert zunächst Aufräumarbeiten. Wir bei Cashcrown messen die Präzision vor jeder Produktionsimplementierung mit einem Golden Set von 50-100 Fragen. Ohne diese Baseline weiß man nicht, wo man startet und wie man Verbesserungen misst.

Nein, wenn die Architektur korrekt aufgebaut ist. Die Verbindung des Agenten verwendet eine Datenbankrolle ohne Berechtigungen für INSERT, UPDATE, DELETE oder DDL. Diese Schicht funktioniert unabhängig vom Modell: Selbst wenn das Modell durch Prompt Injection oder einen Fehler eine datenmodifizierende Abfrage generiert, lehnt die Datenbank sie mit einem Berechtigungsfehler ab. Zusätzlich gibt es einen Guardrail, der SQL vor dem Senden an die Datenbank parst und jede Abfrage blockiert, die andere Anweisungen als SELECT enthält.

Der Agent signalisiert eine Eskalation statt einer Antwort: Er zeigt die generierte Abfrage an, gibt den Grund für die Unsicherheit an (z. B. unbekannter Begriff, keine Übereinstimmung mit dem Schema, leeres Ergebnis) und bittet den Operator um Überprüfung oder Vereinfachung der Frage. Dieses Verhalten ist beabsichtigt, nicht fehlerhaft. Ein System, das selbstbewusst auf Fragen außerhalb seines Bereichs antwortet, ist gefährlicher als eines, das seine Wissenslücken eingesteht. Das Muster Structured Output mit den Feldern confidence und requires_review ermöglicht es dem Agenten, diese Entscheidung formal zu signalisieren.

Die praktische Grenze liegt bei 30-50 Tabellen im Schema-Kontext bei typischen Größen des Kontextfensters moderner Modelle. Bei größeren Datenbanken wird eine Schichtung verwendet: Der Agent arbeitet mit Views, die vom Dateningenieur vorbereitet wurden, nicht mit dem Rohschema. Alternativ wird das Schema dynamisch basierend auf der Frage gefiltert, was den Kontext auf die für die jeweilige Abfrage relevanten Tabellen beschränkt. Beide Techniken erfordern zusätzliche Konfiguration.

Wir beginnen mit einem Audit des Schemas und des Geschäftswörterbuchs (1 bis 2 Wochen, abhängig von der Anzahl der Tabellen und dem Zustand der Dokumentation). Dann folgen die Konfiguration der Guardrails, der Tabellen-Allowlist und der Read-Only-Rolle. Anschließend der Golden Set: 50-100 Fragen mit erwarteten Ergebnissen, Messung der Baseline-Präzision. Pilotphase mit Benutzern für 2-4 Wochen mit vollem Eskalationsmonitoring. Volle Autonomie erst nach Validierung der Präzision und der Eskalationsrate unter den vereinbarten Schwellenwerten. Einstieg über Bewertung der Einsatzbereitschaft oder Kontakt.