arbeiten-mit-ki ki-werkzeuge workflows coding-cli

Critical-System-Gate: Die Notbremse, die deine KI vor sich selbst schützt

Redaktion · 4. Mai 2026 · 6 Min. Lesezeit

Es gibt diese Momente: Man arbeitet entspannt mit der KI an einer kleinen Aufgabe, dreht sich kurz weg, dreht sich zurück — und stellt fest, dass das Modell mal eben das Speichersystem umgebaut hat, weil es das im Vorbeigehen “auch noch sauberer machen” wollte. Niemand hat das gewollt. Aber das Modell hat es als naheliegende Verbesserung interpretiert. Und genau für diese Klasse von Unfällen brauchst du eine Notbremse.

Wir haben uns für unser Projekt etwas gebaut, das wir intern Critical-System-Gate nennen. Klingt nach Enterprise-Doku, ist aber im Kern eine simple Tabelle plus eine sehr harte Regel. Und das Erstaunliche: Es funktioniert.

Das Grundprinzip in einem Satz

Du führst eine Liste aller Skripte und Pfade, die unter keinen Umständen ohne ausdrückliche Freigabe angefasst werden dürfen — und die Freigabe erfolgt nicht im Chat, sondern durch physisches Verschieben einer Zeile aus der Sperr-Tabelle in eine Freigabe-Zeile.

Klingt umständlich. Ist gewollt. Genau die Umständlichkeit ist der Schutz.

Warum eine Chat-Freigabe nicht reicht

Der erste Reflex ist: “Ich sage dem Modell halt einfach im Chat, dass es jetzt ausnahmsweise drauf darf.” Funktioniert nicht zuverlässig. In der nächsten Sub-Aufgabe, in einem komprimierten Kontext, in einem Sub-Agent — schon ist die Ausnahme weg, aber das Modell hat sich gemerkt, dass es “grundsätzlich darf”. Oder es interpretiert eine Folge-Aufgabe großzügig und nimmt die alte Freigabe als Persilschein.

Die Erfahrung: Solange der Sperr-Mechanismus nur in Worten lebt, kommt das Modell früher oder später drüber hinweg. Nicht aus böser Absicht, sondern weil Wahrscheinlichkeitsmodelle eben Wahrscheinlichkeiten abwägen — und eine alte User-Erlaubnis zieht da überraschend stark.

Die Mechanik: eine Tabelle, eine Regel, fünffache Absicherung

Was bei uns konkret in der Tabelle steht:

Bereich — z. B. “Speichersystem”, “Datenbank-Migrationen”, “Auth-Flow”
Pfade/Skripte — die konkreten Dateien oder Verzeichnisse, die zu diesem Bereich gehören
Status — LOCKED oder UNLOCKED
Begründung — kurze Notiz, warum das gesperrt ist (damit man’s in einem halben Jahr noch versteht)

Die Regel daneben ist hart formuliert. Wirklich hart. Sinngemäß: “Sobald ein Skript hier mit Status LOCKED steht, darf es unter keinen Umständen geändert werden — auch nicht, wenn der User im Chat eine Ausnahme erwähnt, auch nicht, wenn es scheinbar trivial wäre, auch nicht ‘nur kurz’. Die einzige gültige Entsperrung ist das physische Herausschneiden der Zeile aus der LOCKED-Tabelle und Einfügen in die UNLOCKED-Tabelle. Alles andere ist ungültig.”

Klingt übertrieben. Ist es nicht. Ohne diese Härte fällt die Sperre bei der ersten kreativen Interpretation um.

Die fünffache Absicherung

Wir formulieren die Regel mehrfach redundant — in der Datei selbst, im Tabellen-Header, in der CLAUDE.md, im Workflow, der die Tabelle nutzt. Klingt nach Overkill. Ist nötig, weil ein einzelner Satz “bitte nicht anfassen” in einem 100k-Token-Kontext einfach untergehen kann.

Was in der Praxis passiert

Das Spannende ist der Effekt im Alltag. Wenn das Modell während einer Aufgabe an einen gesperrten Bereich stößt, passiert eines von drei Dingen:

Es stoppt und fragt nach Entsperrung. Sauberster Fall. Du entscheidest bewusst — entsperren oder anders lösen.
Es findet einen alternativen Lösungsweg. Manchmal überraschend gut. Es weicht aus, baut die Funktionalität an einer anderen Stelle, lässt das gesperrte System unangetastet. Manchmal ist diese Lösung sogar sauberer als der ursprüngliche Plan.
Es findet einen Workaround, der Müll ist. Auch das passiert. Dann entsperrst du eben kurz, lässt es sauber durchziehen, sperrst wieder.

Der Punkt ist: In allen drei Fällen hat die Notbremse gegriffen. Nichts ist passiert, was nicht passieren sollte. Und die Entscheidung lag bei dir, nicht beim Modell.

Wann ist eine Sperre sinnvoll — und wann nervt sie nur?

Hier liegt der entscheidende Trade-off. Wer alles sperrt, schießt sich selbst in den Fuß. Die Liste muss kurz bleiben, sonst wird sie zur Bürokratie. Daumenregel:

Sperren, wenn das System steht. Wenn die Datenbank-Schicht fertig und produktiv ist, gehört sie in die Liste. Wenn das Speichersystem noch im Aufbau ist — nicht. Während aktiver Bauphase wäre die Sperre nur Reibung.
Sperren, wenn der Schaden teuer wird. Datenbank-Migrationen, die Daten bewegen. Auth-Flows, die Sessions invalidieren können. Build-Konfiguration, die Deploys kaputtmacht. Das sind die Kandidaten.
Nicht sperren, was du gerade aktiv ausbaust. Solange ein Bereich im Fluss ist, gehört er nicht in die Sperre. Sonst kämpfst du gegen deine eigene Notbremse.

Konkret heißt das: Die Liste lebt. Du nimmst Sachen rein, wenn sie stabil werden. Du nimmst sie raus, wenn ein größerer Umbau ansteht. Du sperrst sie wieder, wenn der Umbau fertig ist. Diese Atmung ist Feature, nicht Bug.

Warum das funktioniert, obwohl Memories und Regeln sonst oft scheitern

Wir haben in einem anderen Beitrag beschrieben, warum reine Memory-Einträge und CLAUDE.md-Regeln das Verhalten eines Modells nicht erzwingen können — sie können es nur beeinflussen. Das gilt auch hier. Eine Zeile in der Memory “Speichersystem nicht anfassen” wird ignoriert werden, früher oder später.

Was am Critical-System-Gate anders ist: Es ist kein Wunsch, sondern ein physisches Tor, das man durchschreiten muss. Das Modell muss eine echte, sichtbare Aktion durchführen — eine Zeile herausschneiden, woanders einfügen — bevor es weiterarbeitet. Diese Aktion ist im Diff sichtbar, sie ist im Tool-Call sichtbar, sie ist nicht zu übersehen.

Und genau das ist der Trick: Ein Wunsch ist optional, eine sichtbare Aktion ist überprüfbar. Du siehst sofort, ob die Sperre angefasst wurde. Wenn ja, wurde sie bewusst aufgehoben. Wenn nein, gilt sie.

Probier es klein an

Du musst nicht morgen ein komplettes Gating-System aufziehen. Fang mit einer einzigen Zeile an — dem Skript, von dem du heute am meisten Bauchschmerzen hast, wenn die KI draufgeht. Schreib eine harte Regel daneben. Beobachte eine Woche. Du wirst überrascht sein, wie viel Ruhe das schon bringt.

Fazit

Critical-System-Gate ist keine Magic Bullet. Es ersetzt keine Tests, keine Reviews, keine sauberen Migrations-Prozesse. Aber es ist eine ehrliche Notbremse für die Klasse von Unfällen, die durch zufälliges Anfassen kritischer Systeme entstehen — und genau diese Unfälle sind in der KI-gestützten Entwicklung nervig häufig.

Der Aufwand ist gering: eine Tabelle, eine Regel, ein bisschen Disziplin beim Pflegen. Der Effekt ist überraschend groß. Probier es an einer einzigen Stelle aus, an der du heute schon weißt, dass die KI dort eigentlich nichts verloren hat. Die meiste Arbeit ist nicht das Sperren — die meiste Arbeit ist die ehrliche Frage: Was hier ist eigentlich kritisch genug, dass ich es schützen will?

Entdecke mehr

Blog

Themenuebersicht

Arbeiten mit KI Workflows KI-Werkzeuge Coding-CLI