KI-Leitplanken, die wirklich greifen: Warum Regeln allein nicht reichen

Wer täglich mit KI-Assistenten in produktiven Repositories arbeitet, kennt die Lücke zwischen Anspruch und Realität. Man schreibt eine CLAUDE.md, pflegt Memory-Einträge, baut Skills und Hooks — und nach zwei Wochen tut das Modell trotzdem genau das, was es nicht sollte. Eine Migration läuft durch, obwohl drei Memory-Zeilen sie verbieten. Eine Datei in einer „Zone: CORE” wird angefasst, obwohl die Regel klar war. Eine Aufräum-Aktion löscht Code, der nicht zur Diskussion stand.

Das ist keine Schlamperei der Modelle — das liegt in der Architektur. Und genau deshalb braucht es einen anderen Umgang mit Regeln als „noch eine bessere Memory schreiben”.

Dieser Artikel bündelt unser kumuliertes Verständnis aus der Praxis: Welche Klassen von Schutz-Mechanismen es gibt, welche wirklich greifen, und warum die meisten Teams ihre Schutzschicht an der falschen Stelle bauen.

Die fundamentale Trennung: Wünsche vs. Zwang

Alles, was du dem Modell in Sprache mitgibst — egal ob im Prompt, in einer Memory-Datei oder in einer CLAUDE.md — ist für das Modell ein Hinweis, keine Anweisung im technischen Sinne. Ein LLM ist kein State-Machine, das Regeln stur abarbeitet. Es ist ein Wahrscheinlichkeitsapparat, der bei jedem Token neu rät, was als nächstes passend wäre. Deine Regel konkurriert in diesem Rate-Vorgang mit allem anderen, was im Kontext steht — und manchmal verliert sie.

Daraus folgt eine harte Konsequenz für jeden ernsthaften Workflow:

• Sprachliche Regeln sind brauchbar für Empfehlungen. Stilfragen, bevorzugte Bibliotheken, Tonalität, Naming-Konventionen — Dinge, bei denen ein gelegentlicher Fehlgriff nicht teuer ist.
• Technische Sperren sind nötig für Zwang. Datenbank-Schreibrechte, Production-Deployments, harte Pfad-Verbote, Geld-relevante Aktionen — Dinge, bei denen ein Fehlgriff schmerzt.

Wer diese Trennung nicht macht, baut sich eine Schutzschicht, die irgendwann reißt — meistens am ungünstigsten Tag.

Die vier Schichten verlässlicher KI-Steuerung

In der Praxis bewähren sich vier Schichten, die übereinander liegen — von weich nach hart:

Schicht 1: Sprachliche Empfehlungen

Das ist die CLAUDE.md, die Memory, die Slash-Commands. Hier landen Konventionen, Stilfragen, Routinen. Diese Schicht ist nicht wertlos — sie deckt 70–80 % der Alltagsfälle ab und macht das Modell ohne ständige Erinnerungen produktiv. Aber sie ist eben nur die erste Schicht.

Schicht 2: Strukturierte Workflows

Statt dem Modell eine offene Aufgabe zu geben und zu hoffen, dass es im richtigen Moment die richtige Regel zieht, zerlegt man komplexe Aufgaben in deterministische Schritte. Jeder Schritt bekommt nur den Kontext, den er braucht. Das Modell entscheidet nicht mehr selbst, in welcher Reihenfolge es vorgeht — der Workflow gibt sie vor.

Wirkung: Der Wahrscheinlichkeitsraum, in dem das Modell sich austoben kann, wird drastisch eingeschränkt. Es kann immer noch im Detail einen Fehler machen, aber es kann nicht mehr „mal eben das Speichersystem refactorn”, weil dieser Pfad im Workflow gar nicht vorgesehen ist.

Schicht 3: Pfad-Sperren mit physischer Freigabe

Für Bereiche, die unter keinen Umständen ohne ausdrückliche Freigabe angefasst werden dürfen — Datenbank, Auth, Speicher-Layer, Production-Configs — reichen sprachliche Regeln nicht. Hier braucht es eine harte Liste: Was ist LOCKED? Was ist UNLOCKED? Die Freigabe erfolgt nicht im Chat, sondern durch physisches Verschieben einer Zeile von einer Tabelle in die andere.

Klingt umständlich. Genau die Umständlichkeit ist der Schutz. Solange die Sperre nur in Worten lebt, kommt das Modell früher oder später drüber hinweg — eine alte Chat-Erlaubnis zieht im Wahrscheinlichkeitskampf überraschend stark. Eine Tabelle, die physisch umgebaut werden muss, kann das Modell nicht selbst manipulieren, ohne dass es auffällt.

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

Schicht 4: Sandbox- und Berechtigungs-Layer

Die unterste Schicht ist technisch: Welche Tools darf das Modell überhaupt aufrufen? Welche Pfade darf es schreiben? Welche Datenbanken sind read-only? Das ist die einzige Schicht, die ohne Mithilfe des Modells funktioniert — und deshalb die einzige, auf die man sich bei wirklich teuren Aktionen verlassen sollte.

Die guten KI-Coding-Umgebungen ziehen hier inzwischen merklich an: Schreib-Operationen auf Datenbanken brauchen explizite Bestätigung, gefährliche Bash-Kommandos werden separat freigegeben. Das fängt einen großen Teil der wirklich teuren Unfälle ab, bevor sie passieren.

→ Tiefer: Datenbank-Unfälle mit KI: Regel-Konflikte und was wirklich schützt

Warum mehrere Schichten zusammen mehr sind als ihre Summe

Der entscheidende Punkt: Keine dieser Schichten ist allein ausreichend.

• Nur Schicht 1 (Regeln in Sprache) ist Glücksspiel.
• Nur Schicht 4 (Sandbox-Sperren) wird so restriktiv, dass man am Ende mehr blockt als das Modell tut — Produktivität sinkt.
• Nur Schicht 2 (Workflows) hilft nicht, wenn das Modell innerhalb eines Workflow-Schritts einen Fehlgriff macht.

Was wirklich greift, ist die Kombination: Sprachliche Empfehlungen für den Alltag, Workflows für komplexe Aufgaben, Pfad-Sperren für kritische Bereiche, technische Berechtigungen als letzte Bastion. Jede Schicht fängt das ab, was die nächst-höhere durchlässt.

Regel-Hygiene: das oft übersehene Querthema

Quer durch alle vier Schichten zieht sich ein Problem, das Teams unterschätzen: Regeln widersprechen sich gegenseitig.

Ein klassisches Beispiel: In einer Memory steht „Bei kleinen, trivialen Sachen einfach machen”. Daneben steht „Datenbank-Migrationen brauchen Freigabe”. Eine kleine Migration fühlt sich trivial an — drei Zeilen SQL, Spalte umbenennen. Das Modell rät, welche Regel hier zieht. Manchmal richtig. Manchmal falsch. Im Konfliktfall rät das Modell, weil keine Hierarchie zwischen den Regeln existiert.

Was hilft:

• Eine zentrale Stelle für die Regel-Wahrheit. Memory, CLAUDE.md, Skill-Definitionen, Slash-Commands — wenn dasselbe Thema an vier Stellen lebt, gewinnt der Zufall.
• Klare Priorität bei Konflikten. Sicherheit schlägt Geschwindigkeit, immer. Wer das nicht explizit verankert, wird irgendwann teuer überrascht.
• Regelmäßiges Aufräumen. Was vor drei Wochen sinnvoll war, kann heute mit einer neueren Regel kollidieren. Einmal im Monat alle Regeln in einer Quelle lesen und auf Konsistenz prüfen.

Die Praxis-Heuristik: Wann reicht Sprache, wann braucht es Zwang?

Eine einfache Faustregel, die im Alltag trägt:

| Konsequenz eines Regelbruchs | Empfohlene Schicht | |---|---| | Stil-Inkonsistenz, kleines Refactoring nötig | Schicht 1 (Sprache) reicht | | Verlorene Stunde, manuelles Aufräumen | Schicht 1+2 (Sprache + Workflow) | | Verlorener Tag, Migration zurückrollen | Schicht 3 (Pfad-Sperre) Pflicht | | Datenverlust, Production-Incident, Geld weg | Schicht 4 (technische Sperre) Pflicht |

Diese Heuristik ist nicht dogmatisch — aber sie zwingt zur Frage, die viele Teams nie stellen: „Was ist der schlimmstmögliche Ausgang, wenn diese Regel reißt?” Sobald die Antwort „Datenverlust” oder „Geld weg” lautet, hat eine Memory-Zeile nichts mehr verloren.

Was diese Reihe abdeckt

Aus dieser Pillar-Seite verzweigen sich die vertiefenden Artikel:

• Die KI macht, was sie will — der Grund-Mechanismus: warum Regeln aus Sprache prinzipiell unzuverlässig sind, und welcher Workflow-Ansatz das Problem strukturell löst.
• Critical-System-Gate — wie eine harte Sperr-Tabelle mit physischer Freigabe in der Praxis aussieht und warum die Umständlichkeit der eigentliche Schutz ist.
• Datenbank-Unfälle mit KI — konkrete Beobachtungen aus dem Alltag: wo sich Regeln gegenseitig im Weg stehen, wie Worktree-Setups die Datenbank in Geiselhaft nehmen, und welche Schicht das Problem strukturell löst.

Fazit

KI-Leitplanken, die wirklich greifen, sind keine Frage besserer Memory-Texte. Sie sind eine Frage richtig geschichteter Mechanismen: weich für den Alltag, hart für kritische Bereiche, technisch für das, wo Sprache nie reicht. Wer das einmal durchgezogen hat, arbeitet entspannter mit den Modellen — nicht weil sie zuverlässiger geworden wären, sondern weil die Schäden dort enden, wo die nächst-untere Schicht greift.

Das ist die nüchterne Realität: Wir bauen nicht mit perfekten Modellen. Wir bauen um unperfekte Modelle herum.