Was diese Woche passiert ist
Google Research hat Gemini-SQL2 vorgestellt. Das Modell übersetzt natürliche Sprache in ausführbaren SQL-Code und erreicht auf dem BIRD-Benchmark 80,04 Prozent Genauigkeit. Das ist mit deutlichem Abstand vor OpenAI und Anthropic. Die Basis ist Gemini 3.1 Pro, das System ist also kein separates Modell, sondern eine spezialisierte Variante.
Text-to-SQL klingt nach einem Nischenthema. Ist es nicht. Wer in einer Bank, bei einem Asset-Manager oder auf einem Trading-Desk arbeitet, kennt das Problem: Die wirklich interessanten Daten liegen in relationalen Datenbanken. Kursdaten, Transaktionen, Positionen, Kundenbestände, Risikokennzahlen. Wer dort eine Frage stellen will, braucht entweder SQL-Kenntnisse oder einen Analysten, der Zeit hat.
80 Prozent Trefferquote auf einem realistischen Benchmark wie BIRD ist ein anderes Niveau als die 50 bis 60 Prozent, die noch vor 18 Monaten Stand der Technik waren. BIRD testet nicht einfache Spielzeug-Abfragen, sondern komplexe Joins über mehrere Tabellen mit realistischen Schemas. Genau die Art von Abfragen, die im Finanz-Backoffice täglich gebraucht werden.
Warum das jetzt für die Finanzbranche zählt
Aus meiner Sicht ist Text-to-SQL einer der unterschätzten KI-Use-Cases für die Finanzbranche. Drei Gründe:
Erstens: Die Datenlage. Im Gegensatz zu vielen Industrien sind Finanzdaten extrem gut strukturiert. Handelssysteme, Portfolio-Management-Systeme, Kernbankensysteme, alles liegt in relationalen Datenbanken mit klaren Schemas. Das ist die ideale Spielwiese für Text-to-SQL.
Zweitens: Der Engpass. Datenanalysten sind teuer und knapp. In jedem mittelgroßen Asset-Manager oder Vermögensverwalter warten Portfolio-Manager, Kundenberater und Risikomanager auf Reports, die ein SQL-kundiger Kollege bauen muss. Wenn dieser Engpass verschwindet, ändert sich die Geschwindigkeit, mit der Entscheidungen getroffen werden können.
Drittens: Die Kontrollierbarkeit. Das ist der entscheidende Punkt. Anders als bei einem LLM, das frei eine Antwort halluziniert, erzeugt Text-to-SQL eine Abfrage. Die kann ein Mensch lesen, prüfen, in einer Testumgebung laufen lassen. Das macht den Use-Case compliancefähig. Genau das fehlt vielen anderen Finanz-KI-Anwendungen.
Typisches Beispiel aus der Beratungspraxis: Ein Vermögensverwalter mit 8 Mrd. Euro AuM hat 14 Portfolio-Manager und 2 SQL-fähige Analysten. Die Manager fragen ständig nach Auswertungen. „Wie hat sich unser Energie-Exposure in den letzten 30 Tagen entwickelt, getrennt nach Mandatsgruppen?”. Solche Fragen warten heute zwei bis fünf Tage. Mit einem produktiv eingesetzten Text-to-SQL-System sind das Minuten.
Die Risiken, die niemand wegreden sollte
Genauigkeit von 80 Prozent heißt im Umkehrschluss: Jede fünfte Abfrage ist falsch. Bei einer Frage nach Bestandsdaten ist das ein Ärgernis. Bei einer Frage, auf deren Basis ein Portfolio-Manager handelt, ist das ein Compliance-Problem.
Deshalb gilt: Text-to-SQL ist kein autonomes System. Es ist ein Beschleuniger für Menschen, die SQL lesen können. Die generierte Abfrage muss sichtbar sein, prüfbar, idealerweise mit Erklärung, was sie tut. Ein Setup, in dem das Modell direkt gegen die Produktivdatenbank läuft und das Ergebnis ungeprüft in ein Reporting fließt, ist fahrlässig.
Zweites Risiko: Datenschutz und Datensouveränität. Gemini-SQL2 ist ein Google-Modell. Wer Schemas und Beispielabfragen an Google sendet, sendet implizit Strukturinformationen über seine Datenhaltung. Für Finanzdienstleister mit BaFin- oder FMA-Aufsicht ist das relevant. Hier wird die Frage wichtig, ob das Modell on-premises oder in einer souveränen Cloud-Region läuft. Google bietet das für Gemini grundsätzlich an, aber die Konditionen und die genaue Variante muss geprüft werden.
Drittes Risiko: Schema-Drift. SQL-Abfragen sind nur so gut wie das Datenbankschema, gegen das sie laufen. Wer regelmäßig Tabellen umbenennt, Felder hinzufügt oder Joins anders strukturiert, muss das Modell entsprechend füttern. Sonst halluziniert es Tabellennamen, die es nicht mehr gibt.
Konkrete Handlungsempfehlung
Für Finanzdienstleister, die Text-to-SQL produktiv einsetzen wollen, drei Schritte:
Schritt 1: Read-only-Pilot mit klar abgegrenzter Datenbasis. Wählen Sie eine Datenbank, in der ein Lesefehler keinen Schaden anrichtet. Reporting-Datawarehouse statt Kernbankensystem. Geben Sie dem Modell Zugriff auf 5 bis 10 Tabellen, nicht auf das gesamte Schema. Testen Sie mit 50 typischen Fragen aus dem Tagesgeschäft. Messen Sie die Trefferquote in Ihrem Kontext. 80 Prozent auf BIRD heißt nicht 80 Prozent auf Ihren Daten.
Schritt 2: Mensch in der Schleife, technisch erzwungen. Bauen Sie das Frontend so, dass jede generierte Abfrage sichtbar ist, bevor sie ausgeführt wird. Mit einer kurzen Erklärung in Klartext, was die Abfrage tut. Ein Analyst muss freigeben. Erst dann wird ausgeführt. Das klingt nach Bremse, ist aber genau der Punkt, der die Lösung auditfähig macht.
Schritt 3: Auswahl der Modellvariante mit der Compliance-Abteilung klären. Bevor Sie Geld in einen Piloten stecken, klären Sie die Frage des Datentransfers. Welche Gemini-Variante kommt in Frage? Vertex AI mit EU-Region? On-premises über Google Distributed Cloud? Welche Verträge gibt es? Was sagt Ihre Auslagerungs-Policy? Diese Fragen sind in der Regel der Engpass, nicht die Technik selbst.
Mein Rat: Warten Sie nicht auf das perfekte Modell. Text-to-SQL ist jetzt gut genug, um in kontrollierten Umgebungen produktiv zu werden. Wer in 12 Monaten noch keinen Piloten hat, wird gegen Wettbewerber antreten, deren Analysten dreimal so viele Auswertungen pro Tag bewältigen. Das ist kein theoretischer Vorteil. Das ist Geschwindigkeit am Markt.