Ist es sicher, mein Schema in ChatGPT einzufügen, um SQL zu bekommen?

Ihr Schema verlässt die Firma, und die erzeugte Abfrage erreicht Sie ohne jede Sicherheitsschicht; das Ausführen liegt komplett bei Ihnen. Für private Experimente in Ordnung, für Firmendaten nicht empfehlenswert.

Wie lege ich einen schreibgeschützten Datenbanknutzer an?

Mit dem GRANT-Befehl der jeweiligen Engine: In PostgreSQL definieren Sie zum Beispiel eine Rolle, die nur SELECT-Rechte hält. Das dauert fünf Minuten und ist auch unabhängig von KI gute Sicherheitspraxis.

Wie sehr kann ich KI-generiertem SQL vertrauen?

Schauen Sie auf die Messung. Wir testen die Erzeugung von PerSight mit Hunderten echter Fragen auf vier Engines; die Ergebnisgenauigkeit liegt in typischen Geschäftsdomänen bei 94 %, die Methode ist offen veröffentlicht. Wer 100 % behauptet, den fragen Sie nach der Methode.

Und wenn ich nicht alle Kontrollen aufsetzen kann?

Nutzen Sie es auf Firmendaten nicht ohne mindestens die ersten beiden: Read-only-Nutzer und sichtbare Abfrage. Diese zwei allein fangen den Großteil des Risikos ab.

← Alle BeiträgeDas PerSight-Team · Zuletzt aktualisiert: 25. Juli 2026 · 6 Min. Lesezeit

Ist KI-generiertes SQL sicher? Die echten Risiken und ihre Kontrollen

AI SQL Generatoren und von ChatGPT geschriebenes SQL sind überall; ist das auf Firmendaten sicher? Vier echte Risiken und je eine konkrete Kontrolle: Read-only-Nutzer, sichtbares SQL, Datenlokalität, Messung.

KI SQL schreiben zu lassen ist inzwischen Alltag: Manche fügen Tabellenstrukturen in ChatGPT ein, andere nutzen einen AI SQL Generator. Entsprechend oft fällt die Frage: Ist das auf einer Firmendatenbank sicher? Kurze Antwort: mit den richtigen Kontrollen ja, ohne sie nein. Gehen wir die vier echten Risiken durch.

Risiko 1: Kann eine erzeugte Abfrage Daten verändern?

Die größte Angst: Das Modell erzeugt ein UPDATE oder DELETE, und jemand führt es unbedacht aus. Die Kontrolle hat zwei Schichten. Erstens auf Datenbankseite: Verbinden Sie sich mit einem Nutzer, der nur SELECT-Rechte hat; dann weist die Engine selbst eine schlechte Abfrage ab. Zweitens auf Werkzeugseite: Ernsthafte Tools blockieren alles außer SELECT schon bei der Erzeugung. PerSight wendet beides an; Schreiben ist technisch unmöglich.

Risiko 2: Erreichen meine Daten das Modell?

In dem Moment, in dem Sie ein Schema oder Beispielzeilen in ChatGPT einfügen, haben diese Inhalte die Firma verlassen; in vielen Organisationen ist das allein schon ein Richtlinienverstoß. Der richtige Aufbau sendet dem Modell nur das Schema (Tabellen- und Spaltennamen) und niemals Zeilendaten. Die Frage an jedes Tool, das Sie prüfen, ist direkt: "Was genau sendest du in die Cloud, und kannst du es mir zeigen?" PerSight zeigt es wortwörtlich in einem Transparenzpanel in der App.

Risiko 3: Was, wenn die Abfrage falsch ist und niemand es merkt?

Das ist das tückischste Risiko, denn es gibt keine Fehlermeldung: Die Abfrage läuft, eine Zahl kommt zurück, und die Zahl ist falsch. Entscheidungen werden darauf gebaut. Zwei Kontrollen wirken zusammen: Das erzeugte SQL muss immer sichtbar und bearbeitbar sein (keine Blackbox), und die Genauigkeit des Tools muss regelmäßig mit offener Methode gemessen werden. Geschäftsentscheidungen an ein Tool zu binden, das seine Genauigkeit nicht misst oder nicht veröffentlicht, heißt Gold mit einer ungeprüften Waage zu wiegen.

Risiko 4: Böswillige Anfragen über natürliche Sprache

Prompt Injection steht ganz oben auf der OWASP-Sicherheitsliste für LLM-Anwendungen: Ein Nutzer (oder in Daten eingebetteter Text) kann versuchen, das Modell zu etwas Unerlaubtem zu überreden. Die Verteidigung besteht nicht darin, den Manieren des Modells zu vertrauen; sie besteht aus harten Toren, die das Modell unabhängig von seiner Ausgabe nicht passieren kann: ein Read-only-Nutzer, eine Sperre für Nicht-SELECT-Befehle und eine sichtbare Abfrage mit menschlicher Freigabe. Steht die Torschicht, bleibt ein überlistetes Modell folgenlos.

Häufig gestellte Fragen

Ist es sicher, mein Schema in ChatGPT einzufügen, um SQL zu bekommen?: Ihr Schema verlässt die Firma, und die erzeugte Abfrage erreicht Sie ohne jede Sicherheitsschicht; das Ausführen liegt komplett bei Ihnen. Für private Experimente in Ordnung, für Firmendaten nicht empfehlenswert.
Wie lege ich einen schreibgeschützten Datenbanknutzer an?: Mit dem GRANT-Befehl der jeweiligen Engine: In PostgreSQL definieren Sie zum Beispiel eine Rolle, die nur SELECT-Rechte hält. Das dauert fünf Minuten und ist auch unabhängig von KI gute Sicherheitspraxis.
Wie sehr kann ich KI-generiertem SQL vertrauen?: Schauen Sie auf die Messung. Wir testen die Erzeugung von PerSight mit Hunderten echter Fragen auf vier Engines; die Ergebnisgenauigkeit liegt in typischen Geschäftsdomänen bei 94 %, die Methode ist offen veröffentlicht. Wer 100 % behauptet, den fragen Sie nach der Methode.
Und wenn ich nicht alle Kontrollen aufsetzen kann?: Nutzen Sie es auf Firmendaten nicht ohne mindestens die ersten beiden: Read-only-Nutzer und sichtbare Abfrage. Diese zwei allein fangen den Großteil des Risikos ab.

Wer diese Kontrollen lieber als Voreinstellung hätte, statt sie einzeln aufzubauen: Genau das ist die Basis von PerSight. Nicht-SELECT-Erzeugung blockiert, Abfrage immer sichtbar, nur Schema und Frage in die Cloud, Genauigkeit gemessen und veröffentlicht. Die Seite persight.ai/de/sicherheit wurde für Ihr IT-Team geschrieben.