KI-generiertes SQL prüfen, bevor Sie es verwenden

Warum eine ausführbare Abfrage trotzdem falsch sein kann

Eine von KI erzeugte SQL-Abfrage kann syntaktisch korrekt sein, laufen und Zeilen zurückgeben, ohne die Geschäftsfrage richtig zu beantworten. Die Datenbank führt die vorgegebenen Operationen aus. Sie weiß jedoch nicht, ob eine Summe der Kennzahl entspricht, die Ihr Team als „Umsatz“ bezeichnet, ob der gewählte Zeitraum stimmt oder ob ein JOIN Datensätze vervielfacht hat. Korrekte Syntax ist lediglich eine Voraussetzung für die Ausführung – kein Beleg für logische Korrektheit.

Das Risiko liegt häufig in plausiblen, leicht übersehbaren Entscheidungen: Tabellen werden über den falschen Schlüssel verknüpft, nicht angeforderte Filter eingefügt, Werte nach einer Vervielfachung von Zeilen aggregiert oder NULL-Werte anders behandelt als erwartet. Bevor Sie eine Abfrage ausführen, sollten Sie erklären können, wofür jede Zeile steht und warum jede Bedingung enthalten ist. Anschließend müssen Sie das Ergebnis mit einer Referenz vergleichen, die nicht auf derselben KI-Generierung beruht.

Dieses Protokoll richtet sich auf analytische Abfragen in relationalen Datenbanken. Es ersetzt weder die Definition von Geschäftsregeln noch eine umfassende Sicherheitsprüfung. Stattdessen beschreibt es eine praktische Abfolge: die Frage präzisieren, das SQL statisch prüfen, den Umfang kontrolliert testen und das Ergebnis validieren. Schreibgeschützte Zugriffe begrenzen mögliche Schäden, garantieren aber nicht die Richtigkeit der Ergebnisse.

Schritt 1: Die Geschäftsfrage in überprüfbare Kriterien übersetzen

Bevor Sie das SQL lesen, legen Sie fest, was die Anfrage bedeutet. „Umsatz des Quartals je Kunde“ lässt wichtige Fragen offen: Brutto- oder Nettoumsatz? Angelegte oder abgeschlossene Bestellungen? Welche Grenzen hat das Quartal? Werden Rückerstattungen abgezogen? Welche Zeitzone gilt? Sind diese Entscheidungen nicht dokumentiert, kann eine scheinbar vernünftige Abfrage eine andere Interpretation liefern.

Halten Sie Kennzahl, Analyseeinheit, Zeitraum, Filter und Gruppierung in einer kurzen Spezifikation fest. Bestimmen Sie außerdem für jedes Datum die maßgebliche Quelle. Steht beispielsweise der Gesamtbetrag in der Bestellkopftabelle und die Produkte in einer Detailtabelle, sollte ausdrücklich festgelegt werden, dass die Kennzahl vor der Summierung eine logische Zeile je Bestellung beibehalten muss. Die KI sollte keine fehlenden Regeln stillschweigend ergänzen.

Klären Sie das tatsächliche Schema und den SQL-Dialekt. Prüfen Sie Tabellen, Spalten, Datentypen, Schlüssel und dokumentierte Beziehungen anhand der Datenbank oder des Datenwörterbuchs. Verlassen Sie sich nicht auf Namen, die lediglich plausibel wirken. Bei einer Umsetzung von natürlicher Sprache in SQL sind das Schema und die Regeln, die dem Modell mitgegeben werden, nützlicher Kontext. Die Ausgabe muss dennoch im Anwendungscode und auf dem Zielsystem geprüft werden. Microsoft Learn zeigt beispielsweise die Erzeugung parametrisierten SQLs und eine nachgelagerte Prüfung auf verbotene Abfragen. Zugleich wird darauf hingewiesen, dass Anweisungen an das Modell die Planung von Sicherheitsmaßnahmen nicht ersetzen.

Fehlt eine notwendige Definition, unterbrechen Sie die Prüfung und klären Sie sie mit der für die Kennzahl verantwortlichen Person. Eine erfundene Bedingung hinzuzufügen, damit die Abfrage „funktioniert“, beseitigt die Unklarheit nicht. Es macht aus ihr lediglich eine Entscheidung, die später schwerer zu erkennen ist.

Schritt 2: Statische Prüfung vor der Ausführung

Lesen Sie die Abfrage von außen nach innen und markieren Sie jede Tabelle, jeden JOIN, Filter, Aggregat, Unterabfrage und jede Fensterfunktion. Vergleichen Sie die verwendeten Objekte mit dem tatsächlichen Schema. Verfolgen Sie anschließend den Weg der Zeilen: Welche Beziehung bringt jeder JOIN ein? Welche Bedingungen schließen Datensätze aus? Wann ändert sich die Granularität? Eine Bedingung ist nicht schon deshalb korrekt, weil ihr Name vertraut klingt.

JOINs verdienen besondere Aufmerksamkeit. Prüfen Sie, ob die verwendeten Schlüssel tatsächlich die richtige Beziehung abbilden, und ermitteln Sie deren Kardinalität: eins zu eins, eins zu viele oder viele zu viele. Enthält eine Tabelle eine Zeile je Bestellung und eine andere eine Zeile je Artikel, kann der JOIN den Bestellbetrag für jeden Artikel wiederholen. Wird der Betrag danach summiert, kann die Summe zu hoch ausfallen, ohne dass ein Syntaxfehler auftritt. Auch ein nachträglich ergänztes DISTINCT belegt nicht, dass die Logik repariert ist.

Prüfen Sie jeden Filter anhand der Spezifikation. Stimmen Statuswerte, Datumsgrenzen – einschließlich oder ausschließlich –, sowie Bedingungen für NULL-Werte? Werden Datensätze ausgeschlossen, die berücksichtigt werden sollten, oder einbezogen, die nicht dazugehören? Bei einer Bedingung wie `spalte = wert` verhalten sich NULL-Werte nicht wie gewöhnliche Werte. Ihr Umgang muss bewusst festgelegt und darf nicht einfach angenommen werden.

Untersuchen Sie Aggregationen und Fensterfunktionen mit einer konkreten Frage: Über welche Zeilenmenge wird jeder Wert berechnet? Prüfen Sie, ob die ausgewählten und gruppierten Spalten zur benötigten Ebene passen. Notieren Sie bei verschachtelten Unterabfragen, welche Zeilen jede Ebene zurückgibt und wie sie mit der nächsten verknüpft ist. Bestätigen Sie abschließend, dass Funktionen und Syntax zum Dialekt des Zielsystems passen.

Schritt 3: Umfang begrenzen und in einer kontrollierten Umgebung ausführen

Führen Sie den ersten Test nach Möglichkeit außerhalb der Produktion aus: in einer isolierten Testdatenbank mit synthetischen Daten oder in einer anonymisierten Kopie, deren Aktualisierung den Regeln Ihrer Organisation entspricht. Mit synthetischen Daten lassen sich gezielte Fälle erzeugen – darunter Duplikate, NULL-Werte und Datumsgrenzen – ohne echte Datensätze offenzulegen. Eine anonymisierte Kopie kann die Verteilung realistischer abbilden. Sie müssen jedoch sicherstellen, dass die Anonymisierung angemessen ist und die Kopie keine Schreibrechte auf die Produktionsdatenbank besitzt.

Richten Sie die Verbindung mit minimalen Berechtigungen ein. Verwenden Sie für einen Abfragetest eine schreibgeschützte Identität und beschränken Sie den Zugriff auf die erforderlichen Tabellen oder Views. Legen Sie außerdem Ressourcengrenzen fest: maximale Laufzeit, Höchstzahl zurückgegebener Zeilen und Möglichkeit zum Abbruch. Auch eine schreibgeschützte Abfrage kann zu viele Ressourcen verbrauchen oder Daten zurückgeben, die der Nutzer nicht sehen darf. Sicherheit und Korrektheit hängen zusammen, sind aber unterschiedliche Prüfkriterien.

Führen Sie von der KI erzeugtes SQL nicht ungeprüft aus. Prompt-Anweisungen können das Verhalten des Modells lenken, bilden aber keine Sicherheitsgrenze. Lassen Sie ausschließlich erlaubte Operationen und Objekte zu, validieren Sie Parameter und verwenden Sie für Werte parametrisierte Abfragen. Microsoft Learn beschreibt ein Beispiel, in dem der Server Zeichenketten als Parameter übergibt und die Abfrage vor der Ausführung prüft. Die dort gezeigte Liste verbotener Wörter ist eine Demonstration und keine ohne Anpassung vollständige Schutzmaßnahme.

Beginnen Sie mit dem kleinstmöglichen Umfang, der die Logik prüft: eine bekannte Entität, ein kurzer Zeitraum oder eine kleine Stichprobe. Falls Sie einen Ausführungsplan untersuchen müssen, tun Sie dies in der dafür zugelassenen Umgebung und berücksichtigen Sie die Kosten. Ziel ist nicht, zu beweisen, dass die Abfrage auf der gesamten Datenbank laufen kann, sondern die relevanten Annahmen sicher zu prüfen, bevor Sie den Umfang erweitern.

Schritt 4: Mit bekannten Fällen testen und Ergebnisse vergleichen

Ein plausibles Ergebnis ist noch keine Referenz. Verwenden Sie für die Validierung Fälle, deren Ergebnis sich unabhängig von der KI-Abfrage vorhersagen lässt. Erstellen Sie kleine Beispiele mit berechenbaren Ergebnissen, Datensätzen an Zeitgrenzen, Entitäten mit und ohne Beziehungen sowie – falls relevant – Zeilen mit NULL-Werten. Bei synthetischen Daten können Sie diese Bedingungen gezielt festlegen.

Vergleichen Sie das Ergebnis mit einer maßgeblichen Referenz: einer von einer Person geprüften vereinfachten Abfrage, einem Bericht mit derselben Definition oder einer manuellen Berechnung für eine kleine Datenmenge. Stellen Sie sicher, dass beide Verfahren denselben Zeitraum, dieselben Filter, Ausschlussregeln und dieselbe Granularität verwenden. Zwei Abfragen sind nicht vergleichbar, wenn sie sich in diesen Punkten unterscheiden – auch dann nicht, wenn sie dieselbe Kennzahl benennen.

Validieren Sie sowohl die Struktur als auch die Werte. Prüfen Sie Zeilenanzahl, doppelte Schlüssel, Summen je Gruppe und Grenzfälle. Soll das Ergebnis eine Zeile je Kunde enthalten, prüfen Sie die Eindeutigkeit. Bei einer Gruppierung nach Monat untersuchen Sie auch Monate ohne Aktivität und Datumsgrenzen. Weicht ein Ergebnis ab, verkleinern Sie den Fall: Untersuchen Sie zuerst die Daten vor dem JOIN, dann nach jedem JOIN und schließlich nach Filtern und Aggregationen. So können Sie feststellen, in welchem Schritt sich der Wert verändert.

Eine Kreuzvalidierung mit Testfällen bietet keine allgemeine Garantie. Ein bekannter Fall kann bestätigen, dass die Abfrage in genau dieser Situation richtig arbeitet, aber nicht unbedingt in allen Zeiträumen und Datenkombinationen. Übernehmen Sie Fälle, die Fehler aufdecken, in Regressionstests. So können Sie prüfen, ob spätere Änderungen denselben Fehler erneut einführen.

Fehler, leere Ergebnisse und Mehrdeutigkeit

Ein Syntaxfehler bedeutet, dass die Datenbank die Abfrage nicht interpretieren kann. Seine Behebung bestätigt jedoch nicht die Logik. Prüfen Sie zuerst Dialekt, Namen und Datentypen, bevor Sie eine neue Generierung anfordern. Wenn Sie um eine Korrektur bitten, beschreiben Sie den konkreten Fehler und behalten Sie die bereits geprüften Geschäftsbedingungen bei. Ein bloßes „Repariere das“ kann dazu führen, dass die Antwort andere Teile der Abfrage verändert.

Ein leeres Ergebnis hat ebenfalls nicht nur eine mögliche Ursache. Ein Filter kann zu restriktiv sein, Groß- und Kleinschreibung oder Format können abweichen, das falsche Datum kann verwendet werden, eine Beziehung kann Zeilen ausschließen oder es gibt tatsächlich keine Treffer. Untersuchen Sie die Bedingungen einzeln in der Testumgebung. Entfernen Sie Filter nicht automatisch, nur um Ergebnisse zu erhalten: Aus einem Interpretationsproblem kann sonst eine Abfrage werden, die Daten außerhalb des vorgesehenen Umfangs einbezieht.

Kann das Modell nicht erklären, woher eine Tabelle, Beziehung oder Regel stammt, behandeln Sie sie als ungeprüft. Präzisieren Sie die Frage anhand der fehlenden Definition oder bitten Sie die für die Kennzahl verantwortliche Person um Klärung. Die Erläuterungen des Modells können helfen, den Vorschlag zu verstehen. Sie sind jedoch kein unabhängiger Beleg für dessen Korrektheit.

Tritt eine Abweichung zwischen SQL und Referenz auf, halten Sie Abfrage, Parameter, Schema-Version, Testfall und beobachtetes Ergebnis unter Beachtung der Datenschutzregeln fest. Beheben Sie die Ursache, nicht nur den sichtbaren Wert. Wiederholen Sie anschließend die betroffenen Prüfungen und ergänzen Sie einen Regressionstest, wenn der Fehler erneut auftreten könnte.

Abschließende Checkliste vor der Übernahme der Abfrage

Bevor Sie KI-generiertes SQL in eine Analyse oder Pipeline übernehmen, prüfen Sie, ob die ursprüngliche Frage eindeutig definiert ist, alle Tabellen, Spalten und Beziehungen im Schema existieren und die JOINs die erforderliche Granularität erhalten. Kontrollieren Sie Filter, Aggregationen, NULL-Werte, Datumsangaben, Funktionen und SQL-Dialekt. Stellen Sie außerdem sicher, dass die Abfrage in einer autorisierten Umgebung mit geeigneten Daten getestet wurde und – soweit passend – nur schreibgeschützte Berechtigungen verwendet.

Das Ergebnis muss eine unabhängige Prüfung mit bekannten Fällen oder vergleichbaren Referenzdaten bestehen. Scheitert diese Prüfung, präsentieren Sie das Ergebnis nicht als bestätigt. Korrigieren oder präzisieren Sie die Abfrage, wiederholen Sie die Tests und dokumentieren Sie die freigegebene Version samt Geltungsbereich. Bei Kennzahlen mit großen Auswirkungen, sensiblen Daten oder komplexen Abfragen ist zusätzlich eine fachkundige Prüfung erforderlich.

Die praktische Regel ist einfach: Eine Abfrage ist erst dann einsatzbereit, wenn sie verständlich ist, auf autorisierte Zugriffe beschränkt bleibt und unter Tests, die der Geschäftsfrage entsprechen, konsistente Ergebnisse liefert. Lässt sich eine dieser Bedingungen nicht belegen, halten Sie die Unsicherheit fest und holen Sie vor der Verwendung eine Prüfung ein.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.