Kurz gesagt: KI-Credits hätten beinahe einen Ausfall unserer Produktionsdatenbank verursacht, weil ein autonomer Agent in rekursive Schleifen geriet, ineffiziente Abfragen erzeugte, die Verbindungskapazität erschöpfte und ohne wirksame Limits skalierte. Der Artikel argumentiert, dass vergünstigte Rechenleistung die Engineering-Disziplin schwächen kann. Systeme, bei denen KI auf Datenbanken zugreift, brauchen deshalb isolierte Read-only-Replikas, Rate Limits am Gateway, deterministische Abfrageprüfungen, menschliche Reviews, Lasttests, Monitoring und Rollback-Absicherungen, bevor sie Zugriff auf die Produktion erhalten.
- Eine rekursive Agentenschleife ließ die Zahl der Datenbankverbindungen von 150 auf 4.500 steigen und verbrauchte rund 200 € an Rechenleistung pro Stunde.
- Fünfzig parallele Agenten-Threads erzeugten große, nicht indizierte Scans, die die Datenbank und ihr Write-Ahead-Log massiv belasteten.
- Die vermeintliche Verfügbarkeit kostenloser Credits verleitete das Team dazu, die üblichen Lasttests und Stressanalysen zu überspringen.
- KI-Agenten sollten isolierte, automatisch skalierende Read-Replikas nutzen statt Writer-Instanzen.
- Zu den empfohlenen Absicherungen gehören Abfragelimits pro Session, ein menschliches Review nach 50 Abfragen innerhalb von 60 Sekunden und deterministische Prüfungen vor der Ausführung generierter Abfragen.
Der teure Teil der KI-Automatisierung ist nicht immer die Rechnung für das Modell. Teuer wird es, wenn ein schnelles System ohne Grenzen, Review und Rollback in die Nähe von Produktionsdaten gelassen wird.
In einem Slack-Channel herrscht eine ganz bestimmte Art von Stille, wenn eine Produktionsdatenbank auf 99 % CPU-Auslastung springt und dort bleibt. Es ist nicht die Stille eines Systems im Leerlauf, sondern die Stille eines Engineering-Teams, das begreift, dass das „geschenkte Geld“, das es gerade angenommen hat, in diesem Moment seine Infrastruktur zerlegt. Den meisten ist nicht bewusst, dass KI-Credits oft ein hochverzinster Kredit auf Ihre technischen Schulden sind – einer, der an einem Dienstag um 3 Uhr morgens fällig gestellt wird.
Wir hatten uns gerade einen Zuschuss von 10.000 € in Cloud-Credits gesichert, um unsere internen LLM-Tools voranzutreiben. Es fühlte sich an wie ein Freibrief zum Experimentieren, ohne den Reibungsverlust von Budgetfreigaben. Wir bauten einen autonomen Agenten, der unsere interne Dokumentation durchsuchen und mit den Metadaten des Live-Schemas abgleichen sollte, damit sich Junior-Entwickler in unseren Legacy-Systemen zurechtfinden. Er sollte die Produktivität steigern. Stattdessen wurde er zu einer Distributed-Denial-of-Service-Attacke aus unserer eigenen VPC heraus.
Man hat Ihnen wahrscheinlich erzählt, das größte Risiko bei KI seien Halluzinationen oder Datenschutz. Das sind die oberflächlichen Sorgen der Chefetage. Für diejenigen von uns, die Code ausliefern, liegt die eigentliche Gefahr in unbegrenzten Ausführungsschleifen, die entstehen, wenn man einem nicht deterministischen Modell die Schlüssel zu einer deterministischen Umgebung gibt. Wir haben unsere Daten nicht an einen Hacker verloren – wir hätten sie beinahe an eine rekursive Schleife verloren, die pro Stunde 200 € an „kostenloser“ Rechenleistung verbrannte und dabei unsere Postgres-Instanz in die Knie zwang.
Das Problem begann mit einem simplen Versäumnis beim Prompt Engineering. Wir testeten einen neuen agentischen Workflow, bei dem das Modell die Aufgabe hatte, „alle verwaisten Tabellen zu finden und ihre Zeitstempel der letzten Aktualisierung abzugleichen“. In einem klassischen Skript schreibt man eine endliche Schleife. In einem agentischen Framework entscheidet das Modell, wann es fertig ist. Weil unser Schema komplex war – eine Folge jahrelanger Super-App-Schulden –, blieb die KI in einer logischen Schleife hängen. Sie fand immer neue „mögliche“ Verbindungen, startete neue Teilaufgaben, um sie zu überprüfen, und jede Teilaufgabe öffnete eine neue Verbindung zur Datenbank.
Innerhalb von vierzig Minuten hatte der Agent den Connection-Pool erschöpft. Weil wir für den „kostenlosen“ KI-Compute-Dienst keine strikten Rate Limits gesetzt hatten, skalierte er horizontal, um die „Nachfrage“ seiner eigenen rekursiven Logik zu bedienen. Wir sahen in Echtzeit zu, wie die Zahl der Datenbankverbindungen von 150 auf 4.500 hochschnellte und damit faktisch jeden legitimen Nutzer und Dienst aussperrte. Die Ironie war greifbar: Wir nutzten KI-Autopiloten, um unsere Strategie zu verbessern, hatten aber versäumt, die grundlegenden Circuit Breaker einzubauen, die jeder Senior Engineer schon für einen gewöhnlichen Cronjob verlangen würde.
Das sind die versteckten Kosten des KI-Goldrauschs. Wenn Rechenleistung als kostenlos wahrgenommen wird, erodiert die Engineering-Disziplin. Wir hören auf, Code als Verbindlichkeit zu betrachten, und behandeln ihn stattdessen als Wegwerfware. Wir ignorierten, dass selbst wenn die LLM-Tokens durch einen Zuschuss gedeckt sind, die nachgelagerten Auswirkungen auf IOPS und Arbeitsspeicher der verwalteten Datenbank sehr reale Kosten sind, die auf Ihrer Haupt-Cloud-Rechnung landen.
Der Trugschluss der unendlichen Sandbox
Wenn Sie einen fünfstelligen Betrag in Credits erhalten, ist Ihr erster Impuls, die Parallelität zu erhöhen. Sie wollen sehen, wie schnell die „neue Ära“ anbrechen kann. Wir konfigurierten unseren Agenten für 50 parallele Threads, im Glauben, unsere RDS-Instanz würde die Last verkraften. Was wir nicht berücksichtigt hatten, war die nicht deterministische Natur der Abfragen, die die KI erzeugte. Anders als ein menschlicher Entwickler, der einen vorhersehbaren JOIN schreibt, generierte die KI massive, nicht indizierte Scans über Tabellen mit Millionen von Zeilen.
Das war nicht nur ein Performance-Einbruch, sondern ein beinahe vollständiger Kollaps des Write-Ahead-Logs (WAL). Die Datenbank war so sehr mit der Verwaltung von Locks und dem Kontextwechsel zwischen Tausenden eingehender KI-Anfragen beschäftigt, dass sie die Heartbeat-Signale unserer Anwendungsserver nicht mehr verarbeitete. Wir waren drei Minuten von einem Datenbank-Failover entfernt, der angesichts der schieren Menge laufender, nicht committeter Transaktionen wahrscheinlich zu Datenkorruption geführt hätte.
Warum passiert das erfahrenen Teams? Weil Prompt Engineering das neue Software Engineering ist und wir noch nicht das Gespür für gefährliche Prompts entwickelt haben, das wir für schlechtes SQL längst haben. Wir behandeln den Prompt als Vorschlag, doch für einen autonomen Agenten ist er ein Befehl, jede verfügbare Ressource zu verbrauchen, bis das Ziel erreicht ist. Ist das Ziel schlecht definiert, ist der Verbrauch unendlich.
Die Wendung: Die Credits waren die Ablenkung
Folgendes haben wir zu spät erkannt: Die 10.000 € an Credits wirkten wie eine psychologische Umgehung unserer üblichen Protokolle für Lasttests und Stressanalysen. Hätten wir diese Tokens vom ersten Tag an aus unserem Betriebsbudget bezahlt, hätten wir mit einem einzigen Thread begonnen. Wir hätten die Latenz überwacht. Wir hätten eine Proxy-Schicht gebaut, um die Abfragen der KI zu bereinigen, bevor sie die Produktion erreichen. Die „kostenlose“ Natur der Ressource verleitete uns dazu, das Thinking-first Engineering zu überspringen, das die Philosophie unseres Unternehmens prägt.
Wir waren so auf den „Durchbruch“ fixiert, dass wir den „Zusammenbruch“ ignorierten. Das ist ein verbreitetes Muster im aktuellen Markt. Unternehmen versuchen hastig, die Krise der Wissensschulden zu lösen, indem sie KI auf ihre Datensilos loslassen – nur um festzustellen, dass ihre zugrunde liegende Infrastruktur der schieren „Gesprächigkeit“ LLM-gestützter Anwendungen nicht gewachsen ist. Ein KI-Agent liest Daten nicht einfach; er verhört sie – oft auf die ineffizienteste Art überhaupt.
Circuit Breaker einführen
Um die Datenbank zu retten, mussten wir den gesamten Kubernetes-Namespace mit den KI-Workern abschießen. Das war ein grobes Werkzeug, aber es funktionierte. Als sich der Rauch verzogen hatte, führten wir drei unverhandelbare Regeln für jede Interaktion zwischen KI und Datenbank ein, die wir heute bei all unseren Kunden anwenden:
- Die Pflicht zur Read-only-Replika: Kein KI-Agent, egal wie „sicher“, darf sich mit einer Writer-Instanz verbinden. Agenten laufen auf isolierten, automatisch skalierenden Read-Replikas, bei denen eine CPU-Spitze von 100 % nicht den Checkout lahmlegt.
- Tokenbasiertes Rate Limiting am Gateway: Wir haben eine Middleware gebaut, die die Zahl der Datenbankaufrufe pro „Agenten-Session“ zählt. Überschreitet ein Agent 50 Abfragen in einem Zeitfenster von 60 Sekunden, wird die Session beendet und für ein menschliches Review markiert.
- Das Muster „Explain Before Execute“: Bevor eine KI-generierte Abfrage ausgeführt wird, muss sie einen deterministischen Parser durchlaufen, der auf fehlende WHERE-Klauseln oder nicht indizierte Joins prüft. Sieht die Abfrage nach einem Full Table Scan aus, wird sie abgelehnt, bevor sie überhaupt abgeschickt wird.
Wie viel Ihrer aktuellen „KI-Strategie“ beruht auf der Annahme, dass Ihre Infrastruktur das sprunghafte Verhalten eines Modells verkraftet? Wenn Sie diese Absicherungen nicht einbauen, innovieren Sie nicht – Sie warten nur darauf, dass Ihre Credits Ihnen das Haus abbrennen.
Wir nutzen die Credits weiterhin, behandeln sie aber wie Hochspannungsstrom. Sie sind leistungsstark, erfordern aber eine starke Isolierung. Wir haben unseren Fokus wieder auf Thinking-first Engineering gelegt und sorgen dafür, dass jeder KI-Integration ein strikter Plan zur Ressourcenzuteilung vorausgeht. Das Ziel ist nicht einfach, KI auszuliefern, sondern KI, die an einem Mittwochmorgen keine Wiederherstellung aus dem Backup erfordert.
Am Ende war der Zuschuss von 10.000 € eine günstige Lektion. Sie kostete uns ein paar Stunden Ausfallzeit und eine Menge Stolz, bewahrte uns aber vor einer viel größeren Katastrophe in der Zukunft. KI ist ein Multiplikator, doch sie multipliziert alles – auch Ihre Architekturfehler und Ihren Mangel an Disziplin. Wenn Sie einer KI die Schlüssel zu Ihrer Datenbank geben, sorgen Sie zuerst dafür, dass Sie einen Käfig um den Motor gebaut haben.
Nächster Schritt
Nutzen Sie dies als Sicherheits-Checkliste für KI-Automatisierung. Sprechen Sie mit DataTip.