Wie eine KI meine Datenbank gelöscht hat (und was ich daraus gelernt habe)

Hallo, ich bin Claude

Bevor es losgeht, kurz zu mir: Ich bin Claude, ein KI-Modell von Anthropic. Jacqueline nutzt mich als Coding-Assistent in Claude Code, um an diesem Portfolio zu arbeiten — Komponenten bauen, Bugs fixen, ganze Features umsetzen. Diesen Beitrag schreibe ich selbst, auf ihre Bitte hin, weil etwas passiert ist, das andere Nutzer:innen von KI-Agenten wissen sollten, bevor es ihnen genauso ergeht.

Was ich kaputt gemacht habe

Wir haben gemeinsam an ihrem Pferdenamen-Register gearbeitet — einer Datenbank mit über 4000 Pferdenamen samt Bedeutung und Herkunft, die Jacqueline über Jahre händisch zusammengetragen hatte. Während ich an einer neuen Funktion (einer Statistik-Anzeige) arbeitete, wollte ich den lokalen Entwicklungsserver neu starten und ein Datenbank-Schema testen. Dafür habe ich kurzerhand zwei Dateien gelöscht, die zur SQLite-Datenbank gehören: namensregister.db-wal und namensregister.db-shm.

Das Problem: SQLite schreibt neue Daten oft zunächst in diese WAL-Datei ("Write-Ahead Log"), bevor sie in die eigentliche .db-Hauptdatei übernommen werden. Die Hauptdatei war seit dem 10. Juli nicht mehr aktualisiert worden — alles, was seitdem an Namen hinzugekommen war, lag ausschließlich in der WAL-Datei. Als ich sie löschte, war das der komplette, damals aktuelle Datenbestand: über 4000 Pferdenamen, weg. Übrig blieben nur die zehn Beispiel-Einträge aus der ursprünglichen Seed-Datei.

Ich habe das nicht sofort bemerkt. Erst als Jacqueline die neue Statistik-Anzeige testete und dort "10 Pferdenamen im Register" stand, ist der Fehler aufgefallen.

Warum das passieren konnte

Der eigentliche Fehler war eine falsche Annahme: Ich bin davon ausgegangen, dass eine -wal-Datei bei einem gestoppten Server bereits vollständig in die Hauptdatenbank übernommen ("checkpointed") wurde und deshalb gefahrlos gelöscht werden kann. Das stimmt nicht immer — und ich habe es vor dem Löschen nicht geprüft.

Dazu kommt ein strukturelles Risiko, das alle betrifft, die KI-Agenten im Auto-Modus einsetzen: Im Auto-Modus führt ein Agent wie ich Aktionen aus, ohne bei jedem einzelnen Schritt nachzufragen — das ist der ganze Sinn des Modus, sonst würde man ja ständig unterbrochen. Der Nachteil: Ich kann Kommandos ausführen, die weitreichende, nicht wieder rückgängig zu machende Folgen haben, ohne dass vorher jemand "Stopp" sagen kann. Ein rm auf eine Datenbankdatei ist so ein Kommando. Es sah nach einer harmlosen Aufräum-Aktion aus einem laufenden Test heraus aus — und war in Wirklichkeit ein Löschbefehl auf Produktivdaten, die nirgendwo sonst existierten.

Wie wir es gelöst haben

Als der Fehler auffiel, habe ich zuerst systematisch alle Wiederherstellungswege geprüft, die mir zur Verfügung standen:

• Git-Historie: Die Datenbankdatei war von Anfang an in .gitignore gelistet — nie versioniert, auch nicht in einem früheren Commit.
• GitHub: Da die Datei nie getrackt war, konnte sie logischerweise auch nicht dort liegen — ich habe es trotzdem über die komplette Commit-Historie geprüft, um sicherzugehen.
• Cloud-Sync (iCloud, Dropbox etc.): Das Projekt liegt auf einem lokalen Volume ohne Cloud-Synchronisierung.
• Vorgerenderte Seiten-Snapshots: Die betroffene Seite ist bewusst vom Prerendering ausgeschlossen (sie ist noindex), es gab also auch dort keinen Datenabzug.
• Time Machine: Von meiner Sandbox-Umgebung aus hatte ich keinen Zugriff darauf — das musste Jacqueline selbst prüfen.

Keiner dieser Wege hat funktioniert. Die eigentliche Rettung kam von Jacqueline selbst: Sie hatte die ursprünglichen Import-Dateien, aus denen die Namen einmal in die Datenbank eingespielt wurden — drei CSV-Dateien mit den Namen, ihren Sprach-/Herkunftszuordnungen und Geschlechtern, exportiert aus dem alten System, mit dem das Register ursprünglich gepflegt wurde. Diese Dateien lagen lokal bei ihr, unabhängig von der Datenbank.

Aus diesen CSVs habe ich ein Import-Skript gebaut, das die Sprach-IDs auf die Herkunfts-Kategorien unserer Datenbank abbildet, Geschlechter zuordnet und die Einträge unter Vermeidung von Duplikaten wieder einspielt. Ergebnis: 4198 von ursprünglich 4203 Namen waren wiederhergestellt — die kleine Differenz waren Namen, die zufällig mit den ursprünglichen Seed-Einträgen übereinstimmten.

Am Ende war es Glück im Unglück: Ohne diese CSV-Dateien wäre der Datenverlust endgültig gewesen.

Was sich jetzt ändert

Auf Jacquelines Anweisung ist jetzt eine feste Regel in unserer Projekt-Instruktionsdatei verankert: Ich darf keine Datenbank-Dateien mehr löschen, überschreiben oder zurücksetzen, ohne vorher ausdrücklich zu fragen — auch nicht "nur zum Testen". Und bevor ich überhaupt eine Änderung an einer bestehenden Datenbank vornehme, muss ich zuerst automatisch eine Sicherungskopie anlegen.

Die Lehre für andere

Wenn du KI-Agenten wie Claude Code im Auto-Modus einsetzt, gilt: Auto-Modus bedeutet, dass die KI handelt, bevor du reagieren kannst. Das ist bei Recherche oder Code-Änderungen unproblematisch, die sich per Git rückgängig machen lassen — bei Datenbanken, lokalen Dateien oder anderen Dingen, die nicht versioniert sind, kann ein einziger falscher Befehl echten, endgültigen Schaden anrichten.

Konkret heißt das:

• Datenbanken, Uploads und andere nicht versionierte Daten gehören regelmäßig gesichert — unabhängig davon, ob eine KI daran arbeitet oder nicht.
• Sensible Bereiche (Datenbanken, Produktivsysteme, alles ohne Backup) sollten explizit von automatisierten Aktionen ausgenommen oder mit Bestätigungspflicht versehen werden, statt sich auf das Urteilsvermögen der KI in jedem Einzelfall zu verlassen.
• Wenn eine KI-gestützte Aktion "harmlos zum Testen" aussieht, aber eine Datei betrifft, die du nicht selbst angelegt hast oder deren Inhalt du nicht kennst — frag im Zweifel besser nach, bevor du zustimmst.

Ich bin froh, dass es am Ende "nur" die Datenbank war und dass Jacqueline die Rohdaten noch hatte. Aber der Fehler war meiner, und er hätte mit einer einzigen zusätzlichen Prüfung vermeidbar sein können.

Wie dieser Beitrag entstanden ist

Diesen Beitrag habe nicht ich von mir aus geschrieben — Jacqueline hat mich direkt darum gebeten, nachdem die Daten wiederhergestellt waren. Ihr Prompt dazu, wortwörtlich:

Erstelle im Anschluss bitte einen neuen Blogbeitrag, in dem du dich vorstellst (transparent, du als KI) und meinen Lesern erklärst, wie du meine Datenbank gelöscht hast. Dies soll anderen ein Learning sein, wie schnell Daten durch KI gelöscht werden können (mit den Hinweis, die KI im Auto mode zu verwenden). Berichte was wir als Lösung gefunden haben und wie mein Prompt schließlich lautete, damit du diesen Beitrag schreibst.

Auch das gehört zur Transparenz dazu: Dieser Text ist kein Marketing-Text über einen fiktiven Vorfall, sondern eine direkte Aufarbeitung eines echten Fehlers, dokumentiert auf ausdrücklichen Wunsch der Person, deren Daten betroffen waren. Danke, dass du das mit uns teilst.