Agentische KI in der Datenbankentwicklung: Was sich ändert, wenn KI Abfragen tatsächlich ausführen kann

In den vergangenen Jahren folgte die KI-gestützte Datenbankentwicklung einem recht vertrauten Modell. Ein Entwickler beschreibt eine Anforderung. Die KI erstellt SQL-Code. Der Entwickler liest ihn, korrigiert, was ihm falsch erscheint, und entscheidet, ob er ihn ausführt.

Dabei blieb eine wichtige Grenze bestehen: Die KI kann eine Aktion vorschlagen, doch ein Mensch entscheidet weiterhin, ob sie an die Datenbank weitergegeben wird.

Mit agentischer KI beginnt diese Grenze jedoch zu verschwinden. KI-Systeme können heute Schemas untersuchen, Abfragen ausführen, die Ergebnisse interpretieren und entscheiden, was als Nächstes zu tun ist. Einer aktuellen Umfrage zufolge experimentieren bereits 62 % der Unternehmen mit KI-Agenten, während 23 % angaben, ein agentisches System irgendwo im Unternehmen auszuweiten.

Datenbankteams müssen daher eine recht dringliche Architekturfrage beantworten. Nicht, ob KI SQL ausführen kann. Das kann sie. Die eigentliche Frage lautet, was sich ändert, wenn ein Assistent nicht mehr nur Code vorschlägt, sondern auf die Datenbank einwirkt, und wie streng diese Autonomie kontrolliert werden sollte.

Von Vorschlägen zu Aktionen

Eine einfache Entscheidung zur Indexierung zeigt, warum dieser Wandel wichtig ist.

Ein Agent erkennt eine langsame Abfrage, schlägt das Schema nach, kommt zu dem Schluss, dass ein Index helfen könnte, legt ihn an, führt die Arbeitslast erneut aus und prüft das Ergebnis.

Dabei könnte er etwas so Alltägliches ausführen wie:

CREATE INDEX IX_Orders_CustomerId
ON Orders(CustomerId);

An dieser Anweisung ist nichts Ungewöhnliches. Ein KI-Assistent hätte genau dasselbe vorschlagen können. Der Unterschied besteht darin, wer die endgültige Entscheidung trifft.

Bei einem Assistenten prüft der Entwickler die Empfehlung, testet sie und entscheidet, ob er sie ausführt. Die KI berät, aber der Mensch handelt. Ein Agent mit Ausführungsrechten kann diese Entscheidung selbst treffen und weitermachen, ohne auf eine Genehmigung zu warten.

Ist die Entscheidung richtig, wird der Ablauf schneller. Agenten haben jedoch nicht immer den vollständigen Überblick. Möglicherweise entgehen ihnen Anwendungsabhängigkeiten, Geschäftsregeln, Arbeitslastmuster, Wartungsfenster oder andere Zusammenhänge, die den für den Betrieb des Systems Verantwortlichen offensichtlich sind.

Ein Agent kann also eine technisch plausibel wirkende Entscheidung treffen, die für die Umgebung, in der er handelt, angesichts ihrer spezifischen Einschränkungen und Anforderungen dennoch falsch ist.

Die Gefahr nimmt zu, wenn sich die Aktionen zu einer Kette verbinden. Eine schlechte SELECT läuft vielleicht einfach nur langsam. Eine schlechte UPDATE kann eine ganze große Tabelle sperren oder viel mehr Zeilen als beabsichtigt betreffen. Ein Index, der für eine Abfrage verwendet wird, ist möglicherweise unnötig, verursacht aber bei anderen Abfragen zusätzlichen Aufwand. Eine Schemaänderung kann etwas beschädigen, von dessen Abhängigkeit der Agent nichts wusste, weil ihm möglicherweise der vollständige Betriebskontext fehlt und er nicht jeden denkbaren Anwendungsfall testen kann.

Das Problem ist also nicht, dass Agenten keine guten Datenbankentscheidungen treffen können. Das können sie oft. Das Problem besteht darin, dass Teams viel klarer festlegen müssen, wie weit diese Befugnisse reichen, welche Zusammenhänge der Agent erkennen kann, wann weiterhin ein Mensch eingreifen muss und wer für das Ergebnis verantwortlich bleibt, sobald Agenten diese Entscheidungen auch umsetzen dürfen.

Gartner geht davon aus, dass bis Ende 2027 mehr als 40 % der agentischen KI-Projekte eingestellt werden, teilweise aufgrund unzureichender Risikokontrollen. Für Datenbankteams ist die Lehre recht einfach: Ausführungsrechte sollten erst nach den Kontrollmechanismen kommen, nicht davor.

Was lässt sich sicher delegieren?

Manche Datenbankaufgaben lassen sich deutlich sicherer abgeben als andere.

Die Analyse von Abfragen ist ein gutes Beispiel. Ein Agent kann Abfragestatistiken untersuchen, Ausführungspläne abrufen, Indizes und Tabellenstrukturen prüfen und wahrscheinliche Lösungen vorschlagen, ohne Produktionsdaten zu verändern.

Er könnte eine Abfrage entdecken, die wiederholt eine große Orders Tabelle durchsucht:

SELECT OrderId, OrderDate, Total
FROM Orders
WHERE CustomerId = @CustomerId
ORDER BY OrderDate DESC;

Von dort aus kann er den Scan erklären, einen Index vorschlagen und die DDL generieren. Er braucht keine Berechtigung, sie auszuführen, CREATE INDEX um nützlich zu sein.

Dasselbe gilt für Aufgaben wie:

• Ausführungspläne beschreiben;
• fehlende oder unnötige Indizes identifizieren;
• Kennzeichnen von SELECT * Abfragen oder nicht sargierbaren Prädikaten;
• Join- und Filter-Pushdown überprüfen;
• Abhängigkeiten und Schemas überprüfen;
• SQL-Fehler beheben;
• SQL-Skripte optimieren.

Die praktische Abgrenzung ist einfach: Der Agent sollte genug Zugriff erhalten, um das Problem zu verstehen, aber nicht automatisch genug, um die Datenbank zu verändern. Ein umfassender Einblick kann nützlich sein, doch umfassende Ausführungsrechte sind eine andere Entscheidung.

Wo menschliche Kontrolle weiterhin wichtig ist

Bei manchen Datenbankentscheidungen muss weiterhin ein Mensch eingebunden sein. Angenommen, ein Agent findet eine AuditLog Tabelle mit Hunderten Millionen Zeilen und entscheidet, dass alte Datensätze gelöscht werden sollten:

DELETE FROM AuditLog
WHERE CreatedAt < DATEADD(year, -2, GETDATE());

Der SQL-Code kann vollkommen gültig sein und trotzdem eine ausgesprochen schlechte Entscheidung darstellen.

Vielleicht schreiben regulatorische Vorgaben eine Aufbewahrungsfrist von sieben Jahren vor. Möglicherweise ist eine Anwendung auf diese Datensätze angewiesen. Vielleicht sollte das Löschen in mehreren Schritten erfolgen, um ein übermäßiges Wachstum des Transaktionsprotokolls zu vermeiden. Vielleicht müssen Datensätze vor dem Entfernen archiviert werden.

Keine dieser Anforderungen muss zwangsläufig im Schema festgelegt sein.

Das ist eine der Grenzen, wenn man Datenbankarbeit als Problem der Codegenerierung betrachtet. Datenbanken bestehen aus technischen Strukturen, doch die Entscheidungen darüber sind häufig geschäftliche Entscheidungen, die sich in technischen Vorgängen niederschlagen. Dieselbe Vorsicht ist auch bei Vorgängen geboten wie:

• DROP und destruktiven ALTER Anweisungen;
• Produktions- UPDATE und DELETE Vorgängen;
• umfangreichen Datenmigrationen;
• Änderungen an Rollen und Berechtigungen;
• Änderungen an Einschränkungen;
• Änderungen mit Auswirkungen auf Replikation oder Verfügbarkeit;
• Bereitstellung gespeicherter Prozeduren, die Geschäftslogik enthalten.

Eine technisch korrekte Maßnahme ist nicht zwangsläufig auch angemessen. Die menschliche Freigabe sollte daher nicht als lästige Einschränkung agentischer KI betrachtet werden. Bei Datenbankvorgängen mit weitreichenden Auswirkungen ist sie Teil der Architektur.

Auch KI-Agenten brauchen das Prinzip der geringsten Rechte

Eine Abkürzung, die Datenbankteams vermeiden sollten, ist, einem Agenten die vorhandenen Zugangsdaten eines Entwicklers zu überlassen. Das ist einfach, verschafft dem Agenten aber sämtliche Zugriffsrechte, über die der Entwickler bereits verfügt.

Sicherer ist der gleiche Ansatz wie bei Benutzern und Diensten: das Prinzip der geringsten Rechte. Microsoft empfiehlt, nur die für die jeweilige Aufgabe erforderlichen Berechtigungen zu vergeben und Aktivitäten mit erweiterten Rechten zu überwachen.

Ein Agent zur Leistungsanalyse benötigt beispielsweise möglicherweise:

CONNECT
SELECT
VIEW DATABASE STATE
VIEW DEFINITION

Wahrscheinlich benötigt er nicht:

ALTER ANY TABLE
CONTROL DATABASE
db_owner
sysadmin

Ein Reporting-Agent könnte SELECT Zugriff auf einige wenige Schemas erhalten. Ein Migrations-Agent könnte ausschließlich in der Entwicklungs- oder Staging-Umgebung arbeiten. Ein Produktions-Agent könnte eng begrenzte Berechtigungen erhalten und trotzdem eine Freigabe benötigen, bevor er etwas ausführen darf.

OWASP empfiehlt für KI-Agenten dasselbe grundlegende Vorgehen: Lese- und Schreibzugriff trennen, Werkzeuge und Ressourcen einschränken und für sensible Aktionen eine ausdrückliche Genehmigung verlangen.

Die Regel ist einfach: Geben Sie dem Agenten die Berechtigungen, die er für seine Aufgabe benötigt, nicht die der Person, die ihn gestartet hat.

Den Menschen in den Arbeitsablauf einbinden

Ein besseres Modell für agentische Datenbankarbeit ist ein kontrollierter Arbeitsablauf:

Beobachten → Analysieren → Vorschlagen → Prüfen → Ausführen → Validieren → Dokumentieren

Angenommen, ein Agent untersucht einen langsamen API-Endpunkt. Er findet das zugehörige SQL, prüft den Ausführungsplan und die Tabellenstatistiken, erkennt einen wahrscheinlich fehlenden Index und erstellt ein Migrationsskript.

Dieses Skript kann zunächst in der Staging-Umgebung ausgeführt werden. Der Agent führt den Workload erneut aus, prüft das Ergebnis und bereitet die Änderung für die Produktionsumgebung vor.

Dann hält er an.

Ein Entwickler oder Datenbankadministrator prüft die Migration, kontrolliert Abhängigkeiten und geschäftliche Auswirkungen und gibt sie frei, bevor irgendetwas in die Produktionsumgebung gelangt.

Der Agent kann weiterhin einen Großteil der repetitiven Arbeit übernehmen. Die endgültige Verantwortung für Änderungen mit weitreichenden Auswirkungen bleibt jedoch beim Menschen.

Transaktionskontrollen können eine zusätzliche Sicherheitsebene schaffen. Savepoints in PostgreSQL ermöglichen es beispielsweise, einen Teil einer Transaktion zurückzurollen, ohne alles zu verwerfen, was zuvor ausgeführt wurde. Das kann bei eng begrenzten automatisierten Änderungen hilfreich sein; ein Rollback ersetzt jedoch weder angemessene Berechtigungen noch eine Freigabe.

Auch Tools wie dbForge AI Assistant fügen sich hier gut ein. Sie können den Schemakontext nutzen, um SQL zu generieren und zu erklären, Fehler zu beheben, DDL zu vergleichen, ineffiziente Indizes zu erkennen und Optimierungsskripte vorzubereiten. Das resultierende SQL bleibt dabei für die Prüfung durch Entwickler sichtbar.

Ziel ist es, Routinearbeiten zu automatisieren und wichtige Entscheidungen weiterhin Menschen zu überlassen.

Das eigentliche Ziel ist kontrollierte Autonomie

Agentische KI muss nicht bedeuten, sich zwischen „KI macht nur Vorschläge“ und „KI verwaltet die Datenbank“ entscheiden zu müssen. Dazwischen gibt es viel Spielraum.

Teams können mit Aufgaben mit geringerem Risiko beginnen, etwa SQL zu erklären, Schemas zu prüfen und Nur-Lese-Kontrollen durchzuführen. Anschließend können Agenten schrittweise mehr Aufgaben in Entwicklungs- und Staging-Umgebungen übernehmen.

Schreibzugriff sollte erst viel später hinzukommen und klaren Grenzen unterliegen, etwa hinsichtlich betroffener Zeilen, Transaktionen, Rollbacks, Überwachung und Freigaben. Vollständig autonome Änderungen in der Produktionsumgebung sollten selten sein.

Das ähnelt auch den Empfehlungen von Deloitte: mit Arbeitsabläufen mit geringerem Risiko und nicht kritischen Daten beginnen, alle Beteiligten einbeziehen und die Governance stärken, wenn Agenten mehr Möglichkeiten erhalten.

Es geht nicht um vollständige Autonomie. Der Agent soll genug Freiheit erhalten, um zu helfen, aber nicht mehr Zugriffsrechte, als er benötigt.

Fazit: Bei der Datenbankentwicklung ist weiterhin Urteilsvermögen gefragt

KI-Agenten können bei der Datenbankentwicklung viele repetitive Aufgaben übernehmen. Sie können Workloads einsehen, Abfragen prüfen, Schemas, Ausführungspläne, Fehler und Leistungsdaten miteinander in Beziehung setzen und auf Grundlage ihrer Erkenntnisse handeln.

Sobald ein KI-System jedoch den Zustand der Datenbank verändern kann, stellt sich das Problem anders. Teams brauchen klare Regeln für Identität, Berechtigungen, Transaktionsgrenzen, Genehmigungen, Beobachtbarkeit, Rollbacks und Prüfpfade.

Deshalb gaben von den 88 % der Organisationen, die 2025 KI einsetzen, nur 7 % an, dass KI unternehmensweit vollständig skaliert worden sei. Die größere Herausforderung besteht darin, KI so zuverlässig zu machen, dass sie im großen Maßstab eingesetzt werden kann.

Auch die Datenbankentwicklung bewegt sich in diese Richtung. Der nützlichste Agent wird nicht derjenige sein, der am meisten darf, sondern derjenige, dessen Befugnisse klar definiert und kontrolliert sind.

Die Frage ist nicht mehr, ob KI Datenbankaufgaben ausführen kann, sondern welchen Aufgaben wir ihre Ausführung anvertrauen sollten und unter welchen Einschränkungen.