Governance, die sich selbst erzwingt

96 % meiner KI-Schutzregeln erzwingen sich selbst. So habe ich das gebaut.

Vor 14 Monaten habe ich eine Entscheidung getroffen, die mein gesamtes Arbeitsmodell verändert hat: Jede Governance-Entscheidung, die ich einmal bewusst treffe, wird sofort in Code übersetzt. Nicht in ein Dokument. Nicht in eine Checkliste. In ausführbaren Code, der automatisch feuert.

Heute habe ich 177 aktive Schutzregeln. 170 davon erzwingen sich vollständig selbst. Kein Mensch muss daran denken.

Wie das System entstanden ist

Es begann nicht als großes Architekturprojekt. Es begann mit einem Fehler.

Im Februar 2025 hat mein KI-Agent versehentlich eine Produktionsdatenbank mit Testdaten überschrieben. Nichts war verloren, das Backup funktionierte, aber ich saß zwei Stunden da und dachte nach. Nicht: Wie verhindere ich genau diesen Fehler? Sondern: Wie stelle ich sicher, dass ich bei jedem zukünftigen Fehler dieser Klasse automatisch geschützt bin?

Die Antwort war ein Hook-System. Jeder Bash-Befehl, jede Dateiänderung, jeder Agent-Output durchläuft vor der Ausführung eine Kette von Guards.

# Auszug aus dem pre-bash-dispatcher.sh
run_guard() {
  local guard="$1"
  local input="$2"

  if bash "$GUARDS_DIR/$guard.sh" "$input" 2>/dev/null; then
    return 0
  else
    echo "BLOCKED by $guard" >&2
    return 1
  fi
}

for guard in destructive_path env_dump firewall_flush mass_update; do
  run_guard "$guard" "$COMMAND" || exit 1
done

Jeder Guard ist ein Shell-Skript. Jedes Skript prüft genau eine Sache. Wenn ein Guard blockiert, wird der Befehl nicht ausgeführt. Keine Ausnahme.

Das Kristallisationsprinzip

Ich nenne es Crystallization: Der Moment, in dem eine bewusste Entscheidung zur automatischen Regel wird.

Das funktioniert so: Wenn ich merke, dass ich zum zweiten Mal über dieselbe Frage nachdenke, schreibe ich einen Guard. Nicht irgendwann. Direkt. Der Guard kostet mich 20 Minuten. Er spart mir danach das Nachdenken für immer.

Beispiel: Ich hatte zweimal hintereinander KI-Output ins Produktionssystem geschoben, ohne ihn zu lesen. Beides ging gut, aber es hätte nicht gut gehen müssen. Also habe ich einen Guard geschrieben, der jede Datei, die in bestimmte Produktionspfade geschrieben wird, durch eine Qualitätsprüfung schickt:

# content_quality_gate.sh
BLOCKED_PATHS="/var/www/prod /etc/nginx /home/deploy"
TARGET_PATH="$1"

for path in $BLOCKED_PATHS; do
  if [[ "$TARGET_PATH" == "$path"* ]]; then
    # Prüfe ob Quality-Gate-Datei vorhanden
    if [[ ! -f ".quality-gate-passed" ]]; then
      echo "ERROR: Kein Quality-Gate für Produktionspfad $TARGET_PATH" >&2
      exit 1
    fi
  fi
done

Das ist kein besonders eleganter Code. Aber er funktioniert. Und er läuft jetzt seit Monaten, ohne dass ich daran denke.

Drei Modelle, die sich gegenseitig prüfen

Governance durch Code ist eine Sache. Aber ich habe noch eine zweite Schicht: Ein Multi-Modell-Review-System.

Bevor kritische Befehle ausgeführt werden, durchlaufen sie drei KI-Modelle mit unterschiedlichen Rollen:

1. Das erste Modell schreibt oder plant die Aktion.
2. Das zweite Modell reviewed den Plan aus der Perspektive eines kritischen Seniors.
3. Das dritte Modell spielt Advocatus Diaboli und sucht explizit nach blinden Flecken.

Erst wenn alle drei zustimmen oder ein definierter Konsens erreicht ist, wird ausgeführt.

# Vereinfachtes Multi-Modell-Review
def review_action(action: str, context: dict) -> ReviewResult:
    drafter_opinion = claude_opus.complete(
        f"Bewerte diese Aktion: {action}\nKontext: {context}"
    )

    critic_opinion = claude_sonnet.complete(
        f"Finde Probleme mit diesem Plan: {drafter_opinion}\nOriginal: {action}"
    )

    devil_opinion = gemini.complete(
        f"Was könnte hier schiefgehen? Plan: {action}\nKritik: {critic_opinion}"
    )

    return synthesize(drafter_opinion, critic_opinion, devil_opinion)

Das klingt nach Overhead. In der Praxis dauert das Review unter drei Sekunden. Der Unterschied zum einmaligen Nachdenken ist: Es passiert jedes Mal. Ohne Ausnahme. Unabhängig davon, wie müde ich bin oder wie viel Druck gerade auf dem Kessel ist.

Was 13 Produktions-Apps mit einem Entwickler wirklich bedeutet

Ich betreibe gerade 13 Produktions-Apps, 86 Container, 24 Datenbanken. Alleine.

Das ist keine Heldenerzählung. Das ist ein Kapazitätsproblem, das ich mit Architektur gelöst habe, weil ich es mit Personal nicht lösen kann.

Ein Governance-Team hätte ich mir nie leisten können. Ein Compliance-Beauftragter wäre bei der Infrastruktur, die ich betreibe, ohnehin überfordert, weil die Änderungsgeschwindigkeit zu hoch ist. Checklisten funktionieren nicht, wenn der Entwickler, der sie ausfüllen soll, dieselbe Person ist, die die Änderung durchführt.

Also musste das System selbst die Governance übernehmen.

Das bedeutet in der Praxis: Wenn ich um 23 Uhr einen Hotfix deploye, prüft das System trotzdem, ob ich in einen geschützten Pfad schreibe. Wenn ich vergessen habe, ein Backup zu machen, blockt der Guard und erinnert mich. Wenn ein Agent versucht, massenweise Dateien zu ändern, wird er gestoppt, bevor er anfängt.

Das beschreibe ich ausführlich in "Läuft ohne mich", wo ich das gesamte Architektur-Modell von der ersten Regel bis zur aktuellen Infrastruktur aufschlüssele.

Lessons Learned aus 14 Monaten

Guards müssen schnell sein. Wenn ein Guard länger als 200 Millisekunden braucht, wird er zum Reibungspunkt. Ich habe mehrere Guards umgeschrieben, die ursprünglich externe API-Calls gemacht haben. Alles, was zu langsam ist, wird irgendwann deaktiviert oder umgangen.

Jeder Guard braucht einen klaren Blockierungsgrund. "Geblockt" ist keine Fehlermeldung. "Geblockt: Massenänderung in Produktionspfad erkannt, maximale Änderungsanzahl: 5, aktuell: 47" ist eine Fehlermeldung. Der Entwickler muss in 10 Sekunden verstehen, warum er gestoppt wurde.

Zu viele Guards töten den Flow. Ich hatte eine Phase, in der ich jeden zweiten Befehl geblockt habe. Das System wurde unbrauchbar. Ich habe dann 40 Guards entfernt und die wichtigsten 30 präziser gemacht. Qualität vor Quantität.

False Positives sind tödlich. Wenn ein Guard legitime Aktionen blockiert, verliert er sein Vertrauen. Dann kommt der Moment, in dem der Entwickler den Guard temporary deaktiviert, und dann kommt der Fehler. Die Präzision jedes Guards ist wichtiger als seine Abdeckung.

Das System muss sich selbst dokumentieren. Jede Guard-Blockierung landet in einem Audit-Log. Ich sehe jede Woche, welche Guards wie oft gefeuert haben. Das zeigt mir, wo das System wirklich belastet wird, und wo Guards vielleicht zu aggressiv sind.

Gute Governance skaliert nicht mit Köpfen

Das ist die Kernthese, und ich meine sie ernst.

Mehr Compliance-Mitarbeiter bedeuten mehr Koordinationsaufwand, mehr Interpretation von Regeln, mehr Raum für menschliche Fehler und mehr Abhängigkeit von der Aufmerksamkeit einzelner Personen.

Code dagegen schläft nicht. Code interpretiert nicht. Code macht keine Ausnahmen, weil gerade Stress herrscht. Code ist konsistent auf eine Art, die kein Mensch erreichen kann.

Das bedeutet nicht, dass Menschen in der Governance keine Rolle spielen. Menschen schreiben die Guards. Menschen entscheiden, was überhaupt geschützt werden muss. Menschen bauen das Urteilsvermögen in das System ein.

Aber sobald eine Entscheidung getroffen ist, sollte sie nicht mehr von menschlicher Aufmerksamkeit abhängen. Sie sollte sich selbst erzwingen.

Wichtigste Erkenntnisse

• Jede Governance-Entscheidung, die zweimal manuell getroffen wird, gehört in Code.
• Guards müssen schnell, präzise und mit klaren Fehlermeldungen ausgestattet sein.
• Multi-Modell-Review ist kein Luxus. Es ist der Ersatz für das Review-Gespräch, das man alleine nicht führen kann.
• False Positives zerstören das Vertrauen in das System schneller als False Negatives.
• Audit-Logs sind keine Bürokratie. Sie sind der Spiegel, der zeigt, ob das System tatsächlich funktioniert.
• Governance skaliert nicht mit Personen. Sie skaliert mit Architektur.

---

Das Buch: Taschenbuch (24,99 EUR) https://amazon.de/dp/B0HDMT162J | E-Book (9,99 EUR) https://amazon.de/dp/B0HDMS2YQ9

---

Dieser Artikel wurde mit KI erstellt, auf Basis meiner eigenen Systeme und Praxiserfahrung.