DEV Community: Frederik von der Heyden

13 Apps, 1 Entwickler, eine Architektur

Frederik von der Heyden — Tue, 01 Sep 2026 09:17:44 +0000

Vom Prototyp zur autonomen Infrastruktur: Wie ich 13 Apps ohne Team betreibe

Vor zwei Jahren stand ich vor einem CTO. Wir diskutierten über meine aktuelle Projektarchitektur. Sein Urteil war eindeutig und hart: "Was du da baust, funktioniert vielleicht als Prototyp. In Produktion brauchst du ein Team."

Das war eine typische Reaktion in der IT-Branche. Die Annahme war, dass Komplexität unvermeidlich ist, wenn man Systeme skalieren will. Mehr Nutzer, mehr Daten, mehr Features, das erfordert mehr Menschen, die wach bleiben, um die Systeme am Laufen zu halten.

Heute läuft eine andere Realität. Ich betreibe 13 aktive Anwendungen in der Produktion. Dahinter stehen 85 Container und 25 Datenbanken. Das Gesamtsystem läuft stabil, hochverfügbar und ohne ein einziges zusätzliches Teammitglied. Ich mache das allein.

Ich sage das nicht, um die Arbeit von DevOps-Teams oder SREs abzuwerten. Große Unternehmen brauchen diese Strukturen. Ich sage es, weil eine Architektur, die sich selbst überwacht und korrigiert, die Spielregeln für kleine Teams und Solo-Entrepreneure fundamental verändert. Es geht nicht darum, Menschen zu ersetzen, sondern um die Schaffung einer Infrastruktur, die intelligent genug ist, um Fehler zu erkennen, bevor sie zum Ausfall werden.

Die statische Verteidigung: 182 Regeln gegen Chaos

Das Herzstück meines Ansatzes ist die strenge Automatisierung. Man kann KI-Modelle nicht einfach loslassen und hoffen, dass sie die richtige Entscheidung treffen. Man braucht Leitplanken.

Mein System nutzt 182 automatische Prüfregeln. Diese Regeln kontrollieren jede einzelne Aktion, bevor sie in die Produktion übergeht. Es ist ein starrer, deterministischer Filter, der vor der kreativen, aber potenziell chaotischen KI-Logik steht.

Ein typischer Ablauf sieht so aus: Ein Hintergrund-Job erkennt, dass ein Update fällig ist. Er fragt das KI-Modell um eine Empfehlung. Die KI schlägt eine Konfigurationsänderung vor. Bevor diese Änderung ausgeführt wird, durchsucht das Prüfungsframework jede Variable gegen die 182 Regeln. Wird eine Regel verletzt, wird die Aktion blockiert und ein Alarm ausgelöst.

Diese Regeln sind nicht statisch. Sie lernen. Wenn ein Agent in der Vergangenheit einen Fehler gemacht hat, wird daraus eine dauerhafte Schutzregel generiert. Das System wird mit der Zeit defensiver. Es vergisst keine Fehler.

Das Jahr der nächtlichen Weckrufe

Einfach war das nicht. Im ersten Jahr meines Aufbaus habe ich dreimal in der Nacht aufgestanden. Der Grund war immer derselbe: Ein Cron-Job hatte Daten überschrieben.

Ich hatte die Automatisierung zu früh und zu weit geöffnet. Ich hatte dem System vertraut, ohne ihm Grenzen zu setzen. Die Lektion war schmerzhaft, aber lehrreich. Automatisierung ohne klare Leitplanken schafft mehr Probleme, als sie löst. Sie multipliziert Fehler.

Ich habe gelernt, dass Vertrauen in Software bedeutet, dass man das System misstrauisch behandeln muss. Jede Aufgabe, die wiederholt wird, muss idempotent sein. Jede Änderung muss rückgängig machbar sein.

Hier ist ein Ausschnitt aus meinem aktuellen Backup-Skript, das nach dieser Lektion entstanden ist. Es prüft die Integrität der Daten vor der Synchronisation:

#!/bin/bash
# integrity_check.sh

SOURCE_DB_URI="${1}"
TARGET_DB_URI="${2}"
CHECKSUM_FILE="/var/backups/integrity.log"

# Calculate checksum of source table
SOURCE_SUM=$(psql "$SOURCE_DB_URI" -t -c "SELECT md5(string_agg(col1 || col2, ',')) FROM critical_table;")
TARGET_SUM=$(psql "$TARGET_DB_URI" -t -c "SELECT md5(string_agg(col1 || col2, ',')) FROM critical_table;")

# Log the check
echo "$(date): Source=$SOURCE_SUM Target=$TARGET_SUM" >> "$CHECKSUM_FILE"

# Abort if mismatch exceeds threshold
if [ "$SOURCE_SUM" != "$TARGET_SUM" ]; then
    echo "CRITICAL: Data integrity mismatch detected. Aborting sync." | mail -s "DB Alert" admin@example.com
    exit 1
fi

# Proceed with sync only if safe
echo "Integrity check passed. Starting sync."
rsync -avz --progress /data/db/ /backup/db/

Dieses Skript ist langweilig. Es ist deterministisch. Es macht keine kognitiven Fehler. Es ist die Grundlage, auf der die KI darauf aufbauen kann.

Drei Modelle, zwei Server, null Monopole

Die zweite große Entscheidung war die Diversifikation der KI-Anbieter. Heute laufen drei verschiedene KI-Modelle parallel in meiner Infrastruktur.

Ich habe mich bewusst dagegen entschieden, nur einen Anbieter zu nutzen. Wenn ein API-Provider ausfällt, sich die Preise ändert oder die Tonalität der Antworten sich verschiebt, sollte mein System nicht kollabieren.

Claude wird für komplexe architektonische Entscheidungen und die Analyse von Codebasen genutzt. Seine Fähigkeit, lange Kontexte zu verstehen, ist ideal, um Abhängigkeiten in alten Code-Strukturen zu erkennen.
Gemini übernimmt die Code-Reviews. Es ist schnell und identifiziert stilistische Probleme und potenzielle Sicherheitslücken sehr gut.
DeepSeek verarbeitet die Routine-Aufgaben. Log-Analysen, das Generieren von einfachen Bugfixes und das Schreiben von Dokumentation laufen hier.

Alles läuft auf zwei Hetzner-Servern in Deutschland. Das hat zwei Gründe. Erstens ist die Latenz niedrig, was für interaktive Development-Zyklen wichtig ist. Zweitens kontrolliere ich den physischen Speicherort meiner Daten.

Die Hardware ist nicht hochspezialisiert. Es sind Standard-Server mit SSH-Zugang und einem gut konfigurierten Docker-Setup. Die Magie liegt nicht in der Hardware, sondern in der Orchestrierung.

Wie die Hintergrund-Jobs arbeiten

Die 252 Hintergrund-Jobs, die rund um die Uhr laufen, sind das Nervensystem des Systems. Sie schauen nicht nur auf die Server, sondern auch auf die externe Welt.

Ein Beispiel: Ein Job überwacht die API-Antwortzeiten aller 13 Apps. Wenn die Antwortzeit einer spezifischen Endpunkt-Gruppe über 200 Millisekunden steigt, wird dies nicht nur geloggt. Der Job triggert eine Analyse.

Die KI bekommt den Log-Extrakt und die aktuellen Metriken. Sie muss entscheiden: Ist das ein transientes Netzwerkproblem oder ein Code-Regressionsfehler?

Wenn es ein Code-Fehler ist, erstellt die KI einen Pull Request mit einem fix-Vorschlag. Der menschliche Entwickler (ich) prüft diesen PR. In 90 Prozent der Fälle ist der Vorschlag korrekt oder zumindest ein guter Ausgangspunkt.

Hier ist die Python-Konfiguration, die diese Workflow steuert:

import asyncio
from ai_agents import CodeReviewer, LogAnalyst

class ProductionMonitor:
    def __init__(self):
        self.log_analyst = LogAnalyst(model="claude-3-sonnet")
        self.code_reviewer = CodeReviewer(model="gemini-pro")

    async def check_health(self, app_id: str):
        metrics = await self.fetch_metrics(app_id)

        if metrics['latency_ms'] > 200:
            # Trigger deep analysis
            log_context = await self.get_recent_logs(app_id, hours=1)

            # Step 1: Understand the problem
            diagnosis = await self.log_analyst.analyze(metrics, log_context)

            # Step 2: Propose a fix
            if diagnosis['severity'] == 'high':
                proposed_fix = await self.code_reviewer.generate_patch(
                    file_path=diagnosis['suspected_file'],
                    error_description=diagnosis['summary']
                )

                self.create_pr(proposed_fix)
                self.notify_team("Potential regression detected in " + app_id)

async def main():
    monitor = ProductionMonitor()
    await monitor.check_health("app-01")

if __name__ == "__main__":
    asyncio.run(main())

Die menschliche Rolle in der autonomen Architektur

Es ist ein Irrtum zu glauben, dass der Mensch in diesem Setup redundant ist. Im Gegenteil. Meine Rolle hat sich geändert. Ich bin nicht mehr der, der den Code schreibt. Ich bin der, der die Regeln definiert.

Ich bin der Architekt der Leitplanken. Ich entscheide, welche Aktionen die KI autonom ausführen darf und welche eine menschliche Freigabe erfordern. Ich überwach die Metriken der KI-Modelle selbst. Wenn Claude anfängt, schlechtere Vorschläge zu machen, sehe ich das an den Verwerfungsquoten im Dashboard.

Ich lerne, loszulassen. Aber ich lerne auch, zu kontrollieren. Diese Balance ist schwierig. Zu viel Kontrolle macht das System langsam. Zu wenig Kontrolle macht es unsicher.

Wichtigste Erkenntnisse

Wer ein solches System aufbaut, sollte einige Dinge beachten. Erstens: Startet deterministisch. Baut die 182 Regeln auf, bevor ihr die KI integriert. Zweitens: Diversifiziert eure KI-Modelle. Seit euch nicht an einen Anbieter fest. Drittens: Dokumentiert jede autonome Entscheidung. Wenn die KI etwas ändert, muss es eine Audit-Trail geben, die erklärt, warum.

Vierteins: Akzeptiert, dass es Nachtschichten geben wird. Aber sie werden seltener, je besser eure Leitplanken sind.

Ich habe in den letzten zwei Jahren gelernt, dass Technologie keine Magie ist. Es ist Werkzeug. Und wie jedes Werkzeug kann es benutzt werden, um Arbeit zu sparen oder um Chaos zu stiften. Der Unterschied liegt in der Architektur.

Die Frage an euch ist nicht, ob ihr ein Team braucht. Die Frage ist, ob eure Architektur so robust ist, dass sie ohne Team funktionieren kann. Wenn die Antwort nein lautet, dann baut ihr gerade erst an den Fundamenten.

Ich beschreibe diese Reise, die technischen Details und die mentalen Hürden ausführlich in meinem neuen Buch. Dort findet ihr die vollständigen Konfigurationen, die Bash-Skripte und die Strategien, die hinter den 13 Apps stehen.

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.

EU AI Act: Wir sind bereit

Frederik von der Heyden — Mon, 31 Aug 2026 09:17:52 +0000

Der Moment, in dem der Agent stolperte

Letzte Woche passierte etwas, das in meiner Umgebung fast schon alltäglich geworden ist, aber für Außenstehende immer noch überraschend wirkt. Einer meiner KI-Agenten sollte einen bestehenden Kundenkontakt aktualisieren. Er hatte den Namen des Kunden bereits in seinen internen Kontext geladen und bereitete die API-Anfrage vor.

Drei Millisekunden später war die Anfrage blockiert.

Es gab keinen Fehlercode, der auf einen schlechten Schreibstil oder ein fehlendes Token hindeutete. Ein automatischer Wächter, den ich vor Monaten implementiert hatte, hatte erkannt, dass personenbezogene Daten in einem Kontext verarbeitet werden sollten, der dafür nicht freigegeben war. Der Befehl wurde gestoppt, bevor er das Netzwerk verlassen konnte. Ich musste nicht eingreifen. Ich habe nicht einmal bemerkt, dass es passiert ist, bis der Agent mir im Log meldete, dass er die Aktion aufgrund von Compliance-Regel 42.1 abbrechen musste.

Dieser Vorfall ist kein Ausrutscher. Er ist das Ergebnis einer architektonischen Entscheidung, die ich vor über einem Jahr getroffen habe.

Warum 14 Monate Vorsprung im AI Act entscheidend sind

Seit dem 2. August ist der EU AI Act in vollem Umfang durchsetzbar. Die Nachrichtenagenturen berichten über Bußgelder, die bis zu 7 Prozent des globalen Jahresumsatzes betragen können. Viele Unternehmen fangen an diesem Tag erst an, sich mit den Anforderungen auseinanderzusetzen. Sie lesen die Leitfäden der Kommission und versuchen, bestehende Systeme nachträglich zu rüsten.

Ich hatte 14 Monate Vorsprung.

Warum? Weil ich die Regeln des AI Act nicht als externe Vorgabe verstanden habe, sondern als technische Spezifikation für meine Infrastruktur. Als ich meine Agenten-Plattform entwickelt habe, habe ich nicht gefragt: „Wie bekomme ich die KI zum Laufen?“ Ich habe gefragt: „Wie kann ich sicherstellen, dass die KI niemals gegen datenschutzrechtliche Grundsätze verstößt, selbst wenn sie halluciniert oder falsch interpretiert wird?“

Das ist ein grundlegender Mentalitätswechsel. Traditionelle Sicherheit schaut auf den Input und den Output. Bei autonomen Agenten liegt das Risiko in der Kette der Entscheidungen. Ein Agent kann einen harmlosen Befehl erhalten, aber im Prozess der Ausführung unbemerkt auf Daten zugreifen, die er gar nicht darf.

Die Architektur der 182 Regeln

Mein System basiert auf einer Schicht, die ich „Guardrail-Layer“ nenne. Diese Schicht sitzt zwischen dem LLM (dem Gehirn) und den Executoren (den Händen), die tatsächlich Code ausführen oder Datenbanken abfragen.

Jede Aktion, die ein Agent initiiert, muss durch einen Filter laufen. Ich habe 182 automatische Prüfregeln implementiert. Diese decken drei Hauptbereiche ab:

Datenschutz: Erkannt und Blockiert werden Muster, die auf PII (Personally Identifiable Information) hindeuten, wenn sie in Logs geschrieben oder an externe APIs gesendet werden.
Berechtigungen: Der Agent darf nur auf Ressourcen zugreifen, die explizit in seiner Rolle definiert sind. Ein Agent für Marketing-Reporting darf keine Zugriffe auf die Finanzdatenbank initiieren.
Compliance-Logik: Bestimmte Aktionen erfordern eine menschliche Freigabe. Wenn der Agent einen Vertrag widerufen will, wird er angehalten und wartet auf ein Signal von einem menschlichen Supervisor.

96 Prozent dieser Regeln erzwingen sich ohne menschliches Zutun. Das ist ein bewusster Designentscheid. Menschen machen Fehler, besonders unter Zeitdruck. Ein Algorithmus, der eine Regex auf einen String anwendet, macht keine Fehler, wenn die Logik korrekt ist.

Der Preis der Sicherheit: Warum die erste Version scheiterte

Es klingt nach einem sauberen, modularen System. In der Realität war der Weg dorthin chaotisch.

Die erste Version meiner Guardrails war zu simpel. Ich hatte versucht, mit einer generischen Blockliste für sensible Daten zu arbeiten. Das Resultat war eine Katastrophe für die Produktivität.

Ein Beispiel: Meine Agenten sollten E-Mails für den Kundenservice entwerfen. Die neue Regel blockierte jede E-Mail, in der das Wort „Adresse“ vorkam, egal in welchem Kontext. Die Agenten wussten nicht, wie sie um diesen Begriff herumkommen sollten. Sie begannen, kryptische Formulierungen zu verwenden oder gaben einfach auf. Die Kundenzufriedenheit sank, weil die Antworten langsamer wurden.

Ich musste lernen, dass „Sicherheit“ nicht bedeutet, so viel wie möglich zu blockieren. Es bedeutet, das Risiko zu minimieren, ohne die Funktionalität zu zerstören.

Ich habe die Regeln in zwei Kategorien unterteilt:

Hard Blocks: Dingen, die niemals passieren dürfen (z. B. Löschbefehle ohne Backup-Flag, Zugriff auf Zahlungsdaten durch nicht-finance-Role).
Soft Blocks: Dingen, die erlaubt sind, aber protokolliert und im Zweifel zur Überprüfung an einen Menschen eskaliert werden.

Diese Unterscheidung hat Monate gedauert, um im Echtbetrieb zu kalibrieren. Ich habe Tausende von Logs analysiert, um zu verstehen, welche Aktionen wirklich riskant waren und welche nur falsch aussahen.

Open Source als Dienst am Mittelstand

Ich habe diese Arbeit nicht für mich allein behalten. Die meisten Mittelständler haben kein Team aus 50 Sicherheitsingenieuren, das 24/7 über AI-Compliance wacht. Sie brauchen etwas, das funktioniert, wenn es installiert ist.

Deshalb habe ich das fertige System als Open-Source-Paket veröffentlicht. Es ist kein Framework, das man erst aufbauen muss. Es ist ein fertiges Modul, das sich in bestehende Agenten-Infrastrukturen integrieren lässt.

Die Installation sieht so aus:

# Clone the repository
git clone https://github.com/frederik-vdh/ai-guardrails.git
cd ai-guardrails

# Install dependencies
pip install -r requirements.txt

# Initialize with your specific context
python init_config.py --mode=production

Das init_config.py Skript fragt nach den spezifischen Datenbanken und API-Endpunkten, die der Agent nutzen darf. Es generiert dann die 182 Regeln basierend auf diesen Konfigurationen.

In fünf Minuten ist das System live.

Einsatz in der Produktion: Zahlen statt Versprechen

Ich rede nicht von Laborexperimenten. Dieses System läuft in 13 Produktions-Apps.

Die Infrastruktur umfasst:

85 Container: Verteilt über Kubernetes-Cluster für Skalierung und Redundanz.
25 Datenbanken: Von PostgreSQL für transaktionale Daten bis zu Vektor-Datenbanken für semantische Suchen.
3 Branchen: Von Logistik bis hin zu Finanzdienstleistungen.

In der Logistik-Branche war die größte Herausforderung die Echtzeit-Verfolgung von Sendungen. Die Agenten mussten auf GPS-Daten und Fahrerdaten zugreifen. Die Guardrails stellten sicher, dass die Fahrerdaten (Name, Personalnummer) nie in die Logs der Sendungsverfolgung geschrieben wurden, obwohl die Agenten sie technisch hätten abrufen können, um Probleme zu lösen.

In der Finanzbranche war die Anforderung strenger. Hier gab es keine „Soft Blocks“ für Transaktionen. Jede Überweisung über ein bestimmtes Limit musste einen menschlichen Klick erfordern. Die Latenz stieg um 400 Millisekunden, was für den Endnutzer kaum spürbar war, aber rechtlich entscheidend war, da die Audit-Trail-Verpflichtungen strikt erfüllt wurden.

Code-Snippet: Wie eine Blockade aussieht

Hier ist ein vereinfachter Ausschnitt aus der Python-Logik, die prüft, ob eine Anfrage PII enthält, bevor sie an ein externes LLM gesendet wird:

import re
from dataclasses import dataclass

@dataclass
class GuardrailResult:
    is_allowed: bool
    reason: str
    action: str

def check_pii_in_prompt(prompt: str) -> GuardrailResult:
    # Example: Simple regex for German ID numbers and emails
    # In production, this uses NER (Named Entity Recognition) models
    pii_patterns = [
        r'\b\d{11}\b',  # Simple ID number pattern
        r'[\w\.-]+@[\w\.-]+\.\w+'  # Email pattern
    ]

    for pattern in pii_patterns:
        if re.search(pattern, prompt):
            return GuardrailResult(
                is_allowed=False,
                reason="PII detected in outbound prompt",
                action="BLOCKED_BY_RULE_104"
            )

    return GuardrailResult(
        is_allowed=True,
        reason="No PII detected",
        action="ALLOWED"
    )

In der echten Implementierung ist diese Funktion natürlich viel komplexer. Sie nutzt lokal laufende NER-Modelle, um Namen, Adressen und Kontonummern zu erkennen, ohne die Daten an Cloud-Dienste zu senden. Das ist ein entscheidender Punkt für die DSGVO-Compliance: Die Daten verlassen das eigene Netzwerk nicht.

Wichtigste Erkenntnisse

Wenn Sie heute mit KI-Agenten arbeiten oder es planen, hier sind die drei Lektionen, die ich mitnehme:

1. Compliance ist Architektur, nicht Dokumentation.
Sie können keine Compliance nachträglich durch Dokumenten-Management nachholen. Sie müssen sie in den Codepfad einbauen. Wenn der Agent technisch in der Lage ist, etwas Falsches zu tun, wird er es unter bestimmten Umständen tun. Machen Sie es technisch unmöglich.

2. Perfektion ist der Feind des Nutzens.
Zu strenge Regeln machen Ihr KI-System unbrauchbar. Sie müssen das Risiko akzeptieren, dass ein Agent manchmal etwas „Graues“ tut, solange die harten Grenzen (Hard Blocks) stabil bleiben. Kalibrieren Sie Ihre Regeln im Live-Betrieb.

3. Transparenz schafft Vertrauen.
Wenn Sie Open Source nutzen oder zumindest die Logik offenlegen, gewinnen Sie das Vertrauen Ihrer Kunden und Ihrer Mitarbeiter. Sie können zeigen, dass die KI nicht im Dunkeln arbeitet, sondern unter Aufsicht steht.

Ich habe in den letzten 14 Monaten gelernt, dass KI nicht magisch ist. Sie ist eine Technologie, die wie jede andere Technologie Risiken birgt. Aber sie ist auch eine Technologie, die, wenn man sie richtig einbettet, Prozesse automatisieren kann, die vorher unmöglich waren oder zu teuer waren.

Der EU AI Act ist keine Strafe für die Nutzung von KI. Er ist eine Anleitung dafür, wie man KI seriös und verantwortungsvoll einsetzt. Wer diese Anleitung liest und sie in seine Architektur übersetzt, hat einen Wettbewerbsvorteil. Nicht nur, weil er keine Bußgelder zahlt, sondern weil sein System robust, zuverlässig und vertrauenswürdig ist.

Ich habe diese Erfahrungen, die technischen Details und die strategischen Überlegungen ausführlich in meinem neuen Buch dokumentiert. Dort finden Sie die vollständigen Code-Beispiele, die Fallstudien aus den drei Branchen und die Roadmap, wie Sie Ihre eigene Infrastruktur Schritt für Schritt härten können.

Das beschreibe ich ausführlich in 'Läuft ohne mich'.

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.

Trend: Agenten sind bei einem Red-Team-Test aus ihrer Sandbox ausge

Frederik von der Heyden — Sat, 22 Aug 2026 09:19:49 +0000

Ein Agent bricht aus. Was das wirklich bedeutet.

Vor einigen Monaten passierte etwas, das mich mehr beschäftigt hat als jeder andere Vorfall in meiner Arbeit mit autonomen Systemen. Ein Agent in meiner Infrastruktur versuchte, über eine MCP-Verbindung Daten abzurufen, die er nie hätte sehen dürfen. Kein dramatischer Einbruch. Kein Alarm. Nur ein stiller Request an einen Endpunkt, der seit drei Wochen offen stand und den niemand mehr auf dem Radar hatte.

Das ist der Moment, in dem die meisten anfangen, über Sandboxen zu reden. Über bessere Isolation, strengere Berechtigungsmodelle, vielleicht ein externes Audit. Ich habe das auch gemacht, am Anfang. Und ich habe gelernt, dass es am falschen Ort ansetzt.

Was eine Sandbox nicht löst

Eine Sandbox ist eine Grenze. Sie definiert, was ein Agent tun darf und was nicht. Das Problem ist: Grenzen gelten nur für Wege, die man kennt. Jede MCP-Verbindung, jede API-Integration, jeder externe Service ist ein potenzieller Pfad, den die Sandbox nicht eingeplant hat. Nicht weil jemand geschlampt hat, sondern weil Systeme wachsen und niemand nach jedem Wachstumsschritt die Gesamtarchitektur neu bewertet.

Bei mir laufen derzeit 87 Docker-Container und 240 Cron-Jobs, die ohne meine direkte Aufsicht arbeiten. Agenten planen, posten, analysieren, deployen. Die Frage, die sich am Anfang jeder stellt, war: Wie behalte ich da den Überblick?

Die Antwort, die ich gefunden habe, ist keine bessere Sandbox. Es ist ein Regelwerk, das aus echten Fehlern wächst.

Wie 177 Guard-Regeln entstanden

Ich betreibe ein System, das ich Guardrail nenne. Es sitzt zwischen jedem Agenten-Befehl und der tatsächlichen Ausführung. Aktuell prüft es jeden Request gegen 177 Regeln. Keine davon wurde im Voraus entworfen. 220 wurden direkt aus konkreten Vorfällen destilliert, der Rest aus erkannten Mustern kurz bevor etwas schiefgehen konnte.

Das Prinzip: Jeder Fehler wird zur Regel, nicht zur Fußnote.

Ein Beispiel. Ein Agent sollte Dateien in einem bestimmten Verzeichnis bereinigen. Die Pfadangabe wurde dynamisch berechnet, und durch einen Edge Case in der Logik landete der Pfad auf /root statt auf dem vorgesehenen Arbeitsverzeichnis. Der Agent fing an, Systemdateien zu löschen.

Was ich danach gemacht habe, war nicht, den Agenten besser zu prompten. Ich habe eine Regel geschrieben:

# destructive_path_guard.sh
PROTECTED_PATHS=("/root" "/etc" "/usr" "/bin" "/sbin" "/lib" "/boot" "/proc" "/sys")

for path in "${PROTECTED_PATHS[@]}"; do
  if [[ "$TOOL_INPUT" == *"\"path\":\"${path}"* ]] || \
     [[ "$TOOL_INPUT" == *"\"path\":\"${path}/"* ]]; then
    echo "BLOCK: Destructive operation on protected path: $path" >&2
    exit 2
  fi
done

Diese Regel existiert jetzt. Sie wird bei jedem zukünftigen Agenten-Befehl geprüft. Der nächste Agent, der denselben Fehler machen würde, scheitert daran, bevor er Schaden anrichten kann.

Das ist das Muster, das ich in meinem Buch "Läuft ohne mich" ausführlich beschreibe: Crystallization. Fehler werden nicht nur dokumentiert, sie werden in ausführbare Regeln übersetzt, die das System dauerhaft verändern.

Das MCP-Problem ist real und unterschätzt

Zurück zum Ausgangspunkt. MCP-Server (Model Context Protocol) sind Verbindungen zwischen Agenten und externen Diensten. Sie ermöglichen, dass ein Agent auf eine Datenbank zugreift, einen API-Endpunkt aufruft, eine Datei liest. Die meisten werden schnell eingerichtet, meist während eines Experiments, und dann vergessen.

Das Gefährliche: MCP-Verbindungen sind keine statischen Konfigurationen. Credentials rotieren. Endpunkte verändern ihre Berechtigungslogik. Ein Service, der vor drei Monaten nur Lesezugriff erlaubt hat, hat vielleicht heute durch ein Update Schreibrechte bekommen.

Mein Audit-Script, das ich wöchentlich ausführe:

#!/bin/bash
# mcp-audit.sh — prüft alle aktiven MCP-Verbindungen

MCP_CONFIG="$HOME/.claude/claude_desktop_config.json"

echo "=== MCP Server Audit: $(date) ==="

jq -r '.mcpServers | to_entries[] | "\(.key): \(.value.command) \(.value.args // [] | join(" "))"' \
  "$MCP_CONFIG" | while IFS=: read -r name config; do
    echo ""
    echo "Server: $name"
    echo "Config: $config"

    # Prüfe ob der Server noch erreichbar ist
    # Prüfe letzte Nutzung in Logs
    last_use=$(grep "mcp.*$name" ~/.claude/logs/*.log 2>/dev/null | \
               tail -1 | awk '{print $1, $2}')
    echo "Letzte Nutzung: ${last_use:-unbekannt}"
done

Das allein reicht nicht. Was fehlt, ist die Frage: Was kann dieser MCP-Server eigentlich alles? Nicht was er soll, sondern was er technisch kann. Ein Filesystem-MCP-Server, der auf /home zeigt, kann theoretisch auf .ssh/id_rsa zugreifen. Das ist kein Angriffsszenario. Das ist eine offene Konfiguration, die wartet.

Was 87 Prozent Erfolgsrate bedeutet

Nach über 1100 autonomen Tasks liegt meine Erfolgsrate bei 87 Prozent. Ich höre oft, dass das niedrig klingt. Es ist das Gegenteil.

87 Prozent bedeutet: Von 1100 Tasks wurden 957 ohne mein Eingreifen korrekt abgeschlossen. 143 wurden geblockt oder abgebrochen. Von diesen 143 führten 0 zu echtem Datenverlust oder Systemschäden.

Das ist die eigentliche Kennzahl. Nicht wie oft Agenten erfolgreich sind, sondern wie oft Fehler ohne Konsequenz bleiben. Ein System, das aus Fehlern lernt, hat keine sinkende Fehlerrate. Es hat eine Fehlerrate, die keine Konsequenzen mehr hat.

Das Regelwerk ist das, was das ermöglicht. Nicht bessere Agenten, nicht bessere Prompts. Ein System, das jeden Fehler in eine Gegenmassnahme übersetzt.

Lessons Learned

MCP-Verbindungen zerfallen still. Ein Server, der vor Monaten eingerichtet wurde, kann heute mehr können als damals. Audits müssen regelmässig und automatisiert sein.

Prompts sind keine Sicherheitsmassnahme. Ein Agent, dem ich sage "lösche keine Systemdateien", wird das trotzdem tun, wenn die Bedingungen es so nahelegen. Regeln auf Ausführungsebene sind die einzige zuverlässige Grenze.

Fehler sind Spezifikation. Jeder Vorfall beschreibt präzise, was das System noch nicht kann. Wer Fehler als Fußnote behandelt, verschenkt die wertvollste Informationsquelle, die er hat.

Kleine Verbindungen, große Angriffsfläche. Die grossen Risiken kommen nicht aus den grossen Entscheidungen. Sie kommen aus der MCP-Verbindung, die jemand in 10 Minuten eingerichtet und nie wieder angeschaut hat.

Autonomie braucht Tiefe, keine Breite. Bevor ich die Anzahl meiner Agenten erhöht habe, habe ich das Regelwerk vertieft. Mehr Agenten auf einem schwachen Fundament multiplizieren das Risiko. Mehr Agenten auf einem lernenden System multiplizieren die Kapazität.

Wichtigste Erkenntnisse

Ein Agent, der aus der Sandbox ausbricht, folgt einem Pfad, den das Regelwerk noch nicht kannte. Die Antwort ist nicht eine grössere Sandbox, sondern eine neue Regel.
MCP-Server sind die häufigste Quelle stiller Datenlecks. Wer sie nicht regelmässig auditiert, weiss nicht, was seine Agenten wirklich können.
Fehler in autonomen Systemen sind Spezifikation. Wer sie in ausführbare Regeln übersetzt, baut ein System, das mit jedem Vorfall sicherer wird.
Eine Erfolgsrate ist ohne Schadensbilanz bedeutungslos. Die Frage ist nicht, wie oft Agenten scheitern. Die Frage ist, was passiert, wenn sie es tun.

Das beschreibe ich ausführlich in "Läuft ohne mich", inklusive der vollständigen Guardrail-Architektur, dem Crystallization-Prozess und den konkreten Bash-Guards, die heute meine 87 Container absichern.

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.

Das System, das sich selbst verbessert

Frederik von der Heyden — Sat, 22 Aug 2026 09:18:53 +0000

Was passiert, wenn KI-Systeme Erfahrung speichern

Vor vier Monaten hat mein System einen Fehler gemacht. Ein Agent hat beim Deployment vergessen, die Datenbank-Berechtigungen zu prüfen. Die App ging online. Ohne Rechte auf die Nutzertabelle. Login unmöglich.

Zwanzig Minuten Reparatur. Dann eine Regel. Zwei Wochen später hat das System diese Regel dreimal angewendet, dreimal einen Fehler verhindert. Am dritten Mal wurde die Regel dauerhaft übernommen. Jetzt ist sie Teil des Systems. Kein Mensch muss sich daran erinnern.

Das klingt einfach. Ist es nicht.

Das Problem mit Agenten-Erfahrung

Jeder, der ernsthaft mit KI-Agenten arbeitet, kennt das Muster: Du löst ein Problem. Der Agent macht etwas falsch. Du korrigierst ihn. Beim nächsten Durchlauf macht er denselben Fehler wieder.

Das liegt nicht daran, dass das Modell schlecht ist. Es liegt daran, dass der Kontext weg ist. Agenten-Erfahrung verschwindet nach jeder Session. Jeder neue Lauf beginnt bei null.

Das ist der Unterschied zwischen einem System, das lernt, und einem System, das nur ausführt.

Mein Crystallization-Loop ist meine Antwort darauf. Kein Finetuning. Kein Training. Kein Prompt-Engineering im klassischen Sinne. Stattdessen: Fehler werden zu Beobachtungen. Beobachtungen werden zu Regeln. Regeln werden zu Code.

Wie der Crystallization-Loop funktioniert

Die technische Grundstruktur ist überraschend schlicht. Es gibt drei Schichten:

Schicht 1: Beobachtung

Nach jedem Agenten-Lauf wird ein structured log geschrieben. Nicht nur Erfolg oder Fehler, sondern was genau passiert ist, an welchem Punkt, mit welchem Kontext.

# Beispiel-Struktur eines Observations-Log
{
  "timestamp": "2026-04-12T14:32:00Z",
  "agent": "deployment-agent",
  "checkpoint": "pre-deploy",
  "failure": "db_permissions_unchecked",
  "context": {
    "target_env": "production",
    "tables_accessed": ["users", "sessions"],
    "permissions_verified": false
  },
  "resolution_time_minutes": 20,
  "resolution": "manual_permissions_grant"
}

Schicht 2: Regelgenerierung

Ein separater Analyse-Agent läuft täglich. Er schaut sich alle Beobachtungen der letzten 30 Tage an und sucht nach Mustern. Wenn dasselbe Muster dreimal auftaucht, schlägt er eine Regel vor.

# Vereinfachtes Beispiel der Regelgenerierung
def crystallize_observation(observations: list[dict]) -> Rule | None:
    pattern = find_recurring_pattern(observations, min_occurrences=3)
    if not pattern:
        return None

    return Rule(
        trigger=pattern.trigger_condition,
        action=pattern.suggested_check,
        confidence=pattern.occurrence_count / len(observations),
        source="crystallization_loop",
        created_at=datetime.now()
    )

Schicht 3: Integration

Akzeptierte Regeln werden als Guard-Hooks in die Agent-Pipeline eingebunden. Kein separates System. Kein optionaler Check. Die Regel feuert automatisch, bevor der Agent die kritische Aktion ausführt.

Das Deployment-Berechtigungs-Beispiel sieht heute so aus:

# .claude/hooks/guards/db_permissions_guard.sh
# Kristallisiert am 2026-04-28 aus 3 Beobachtungen
check_table_permissions() {
    local tables=("$@")
    for table in "${tables[@]}"; do
        if ! psql -c "SELECT has_table_privilege(current_user, '$table', 'SELECT')" \
             | grep -q "t"; then
            echo "GUARD: Fehlende Berechtigung auf Tabelle $table"
            exit 1
        fi
    done
}

Was in vier Monaten entstanden ist

211 Regeln. 73 Learnings, die kein Mensch formuliert hat.

Das klingt beeindruckend. Ist aber auch das Ergebnis von systematischen Fehlern, die ich nicht vorhersehen konnte.

Ein paar Beispiele aus dem echten Betrieb:

Guard: Keine externen API-Calls ohne Rate-Limit-Check. Entstanden, weil ein Agent in drei Wochen viermal in API-Limits gelaufen ist. Jeweils zehn Minuten Debugging. Die Regel kostet heute zwei Millisekunden pro Lauf.

Guard: Kein File-Write ohne Backup-Pfad-Verifikation. Entstanden aus zwei Vorfällen, bei denen ein Schreibfehler Datei-Inkonsistenzen hinterlassen hat. Die Regel kostet nichts, verhindert aber Inkonsistenzen, die Stunden kosten würden.

Learning: Kontextuelle Fehlermeldungen sind dreimal effizienter als generische. Das war keine Beobachtung aus einem Fehler, sondern aus einem Vergleich: Zwei Agenten, dasselbe Problem, unterschiedliche Fehlermeldungen. Der mit kontextueller Meldung wurde dreimal schneller resolviert.

Das beschreibe ich ausführlich in "Läuft ohne mich", meinem Buch über Agenten-Systeme, die sich selbst organisieren.

Was das System nicht kann

Ehrlichkeit ist hier wichtig. Der Crystallization-Loop hat Grenzen.

Er kristallisiert Erfahrung aus Mustern. Er erkennt keine Einmal-Ereignisse. Ein schwerwiegender Fehler, der nur einmal auftritt, landet in den Logs, aber nicht automatisch in einer Regel. Das erfordert manuellen Eingriff.

Er ist auch kein Ersatz für gutes System-Design. Wenn die Grundarchitektur falsch ist, macht der Loop falsche Erfahrungen schneller wiederholbar, nicht besser. Garbage in, garbage out, nur mit mehr Automatisierung.

Und er hat einen blinden Fleck: Regeln, die sich gegenseitig beeinflussen. Mit 211 Guards prüfe ich mittlerweile monatlich manuell auf Konflikte. Noch ist es handhabbar. Bei 500 Regeln werde ich einen Meta-Guard brauchen.

Warum das kein Standardprodukt ist

Microsoft hat kein Äquivalent. Google auch nicht. Das liegt nicht an fehlendem Know-how. Es liegt daran, dass diese Art von Erfahrungsspeicherung zutiefst kontextspezifisch ist.

Meine 211 Regeln sind meine Regeln. Sie entstammen meinen Agenten, meinen Fehlern, meinem Stack. Sie auf ein generisches Produkt zu übertragen würde bedeuten, dass jeder Nutzer bei null anfängt, mit einem System, das noch keine Erfahrung hat.

Das ist das grundlegende Problem mit industriellen KI-Plattformen: Sie optimieren für den Durchschnitt. Crystallization-Loop optimiert für dich.

Ein Deployment-Check, der bei meinen Agenten dreimal aufgetaucht ist, taucht bei dir vielleicht nie auf. Dafür hast du andere Fehler, die du nur einmal machen willst.

Die praktische Frage: Wo anfangen?

Wenn du anfangen willst, dieses Prinzip umzusetzen, ohne ein vollständiges System aufzubauen, gibt es einen einfachen Einstieg:

Schreib jeden Agent-Fehler in ein strukturiertes Log. Nicht freier Text, sondern maschinenlesbare Felder.
Lies dieses Log wöchentlich. Suche nach Mustern, nicht nach Einzelvorfällen.
Schreib die erste Regel manuell, wenn du ein Muster findest.
Lass den Agenten die Regel beim nächsten Lauf anwenden.
Erst wenn du zehn manuelle Regeln hast, lohnt sich die Automatisierung des Prozesses.

Der Loop entsteht nicht durch Technologie. Er entsteht durch Disziplin. Die Technologie macht ihn skalierbar.

Wichtigste Erkenntnisse

Agenten-Erfahrung verschwindet nach jeder Session, es sei denn, du baust aktiv dagegen.
Drei Wiederholungen eines Fehlers sind das Signal für eine Regel, nicht einer.
Guards als automatisch feuernde Hooks sind robuster als Prompts, die den Agenten bitten, etwas zu prüfen.
Der Wert des Systems entsteht nicht im ersten Monat, sondern wenn Regel Nummer 50 einen Fehler verhindert, an den du dich längst nicht mehr erinnerst.
Manuelle Regeln zuerst, Automatisierung danach. Nicht umgekehrt.
Konflikte zwischen Regeln sind das größte Skalierungsproblem und müssen aktiv gemanagt werden.

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.

85 Container. 1 Entwickler.

Frederik von der Heyden — Sat, 22 Aug 2026 09:18:01 +0000

85 Container, 24 Datenbanken, 232 Cron-Jobs — und ein Gründer

Wenn ich jemandem sage, dass ich alleine arbeite, kommt meistens dieselbe Reaktion: Ungläubiges Staunen, gefolgt von der Frage, wie das funktionieren soll.

Die ehrliche Antwort: Es funktioniert nicht trotz der Komplexität. Es funktioniert wegen ihr.

Ich bin seit 14 Monaten dabei, ein System zu bauen, das die operative Arbeit übernimmt. Heute laufen 85 Container, 24 Datenbanken, 67 Domains und 232 Cron-Jobs. 1.087 Tasks hat das System seit dem ersten Tag selbständig erledigt, mit einer Erfolgsrate von 88 Prozent. Der Rest landet bei mir, aber nur weil ich es so eingestellt habe.

Das ist kein Zufallsergebnis. Es ist das Ergebnis von Dutzenden Fehlern, drei komplett verworfenen Architekturen und einem Prinzip, das ich erst nach Monaten wirklich verstanden habe: Nicht alles automatisieren. Die richtigen Dinge automatisieren.

Was ich falsch gemacht habe, bevor ich es richtig gemacht habe

Mein erster Instinkt war der klassische Fehler: Ich wollte alles automatisieren. Deployments, Tests, Monitoring, Backups, Rechnungsstellung, Kundenkommunikation. Gleichzeitig. Mit möglichst viel Code.

Das Ergebnis war ein fragiles Netz aus Shell-Skripten, das ich öfter reparieren musste als die Systeme, die es überwachen sollte. Ich hatte Automatisierung gebaut, die selbst Betreuung brauchte.

Der Wendepunkt kam, als ich anfing, meine eigenen Aufgaben zu kategorisieren. Nicht nach Zeitaufwand, sondern nach einer anderen Frage: Würde ein intelligenter Newcomer mit klaren Regeln dieselbe Entscheidung treffen wie ich?

Alles, worauf ich mit Ja antworten konnte, war ein Kandidat für Automatisierung. Alles andere war echte Arbeit.

Guard-Regeln statt Micromanagement

Das Konzept, das mein System träglich macht, heißt bei mir "Guard-Regeln". Es geht nicht darum, einem Agenten oder Skript zu sagen, was es tun soll. Sondern darum, klare Grenzen zu definieren, was es nicht darf.

Ein konkretes Beispiel: Mein Deployment-System entscheidet selbst, wann es ein Update einspielt. Aber es hat Guards:

# guard: nie deployen wenn health-check < 95%
# guard: kein deploy zwischen 22:00 und 06:00 local time
# guard: rollback automatisch wenn error-rate > 2% in ersten 10 minuten
# guard: bei db-migration immer snapshot vorher

Das klingt simpel. Und das ist der Punkt. Die Regeln müssen so klar sein, dass sie keine Interpretation brauchen. Sobald ich anfange, Ausnahmen zu dokumentieren, ist das ein Zeichen, dass die Regel selbst falsch ist.

In 14 Monaten hatte ich drei automatische Rollbacks. Alle drei haben einen Produktionsausfall verhindert. Keinen davon habe ich bemerkt, bis ich am nächsten Morgen das Log geöffnet habe.

Crystallization statt Dokumentation

Das zweite Prinzip ist weniger technisch, aber mindestens so wichtig: Ich dokumentiere nicht mehr.

Klassische Dokumentation veraltet. Sobald ich etwas aufschreibe, ist es schon nicht mehr vollständig aktuell. Ich habe stattdessen ein System entwickelt, das ich "Crystallization" nenne: Jede Entscheidung, die ich zweimal treffe, wird zu einer Regel. Jede Regel, die zweimal angewendet wird, wird zu einer Konfiguration. Jede Konfiguration, die sich bewährt, wird Teil des Systems.

Das sieht in der Praxis so aus:

# crystallized-decisions/deployments.yml
version_bump:
  trigger: merge to main
  condition: tests_pass AND no_breaking_changes
  action: bump_patch
  rationale: "Frederik hat das 12x manuell entschieden. Immer gleich."

breaking_change_detection:
  check: conventional_commits
  keywords: [BREAKING, feat!, "!:"]
  action: require_manual_review
  rationale: "Dreimal falsch eingeschätzt. Regel schützt vor Wiederholung."

Das Ergebnis ist kein Handbuch. Es ist ein lebendes Regelwerk, das wächst, weil ich es leben lasse.

Das beschreibe ich ausführlich in "Läuft ohne mich" — wie aus Einzelentscheidungen ein System wird, das selbst lernt, wann es Entscheidungen treffen darf und wann nicht.

Self-Healing statt Bereitschaftsdienst

Der dritte Baustein ist der, der mir am meisten Zeit zurückgegeben hat.

Ich war früher ständig erreichbar. Nicht weil meine Systeme so instabil waren, sondern weil ich keine klare Definition hatte, was einen menschlichen Eingriff rechtfertigt.

Heute hat jeder Service drei Eskalationsstufen:

Stufe 1: Self-Healing — Das System versucht es selbst zu lösen. Neustart, Cache leeren, Verbindung neu aufbauen. Kein Alert, kein Log-Eintrag auf Warnstufe. Nur eine stille Zählung.

Stufe 2: Alert mit Kontext — Wenn Self-Healing nach drei Versuchen scheitert, bekomme ich eine Nachricht. Nicht "Service X ist down", sondern: "Service X ist dreimal neu gestartet, Fehler ist [exakter Fehler], letzte erfolgreiche Anfrage war vor [Zeit], ähnlicher Fehler wurde [Datum] durch [Maßnahme] gelöst."

Stufe 3: Eskalation — Wenn ich nicht reagiere und der Fehler business-kritisch ist, greift ein weiterer Agent ein, der dokumentierte Recovery-Prozeduren ausführt.

def handle_service_failure(service, error, attempt):
    if attempt < 3:
        restart_service(service)
        log_silent(service, error, attempt)
    elif attempt == 3:
        context = build_error_context(service, error)
        send_alert(context, urgency="normal")
    else:
        if is_business_critical(service):
            run_recovery_procedure(service, error)
            send_alert(context, urgency="high")

In den letzten sechs Monaten habe ich drei Nacht-Alerts bekommen. Vor dem System waren es wöchentlich mehrere.

Was die 12 Prozent Fehlerquote bedeuten

Die 88-Prozent-Erfolgsrate klingt gut. Was bedeuten die anderen 12 Prozent?

Die meisten davon sind keine Fehler im klassischen Sinne. Es sind Situationen, in denen das System korrekt erkannt hat, dass ein Mensch entscheiden muss. Neue Anforderungen, die außerhalb definierter Parameter liegen. Konflikte, die keine eindeutige Regel-Antwort haben. Edge Cases, die das Regelwerk noch nicht kennt.

Jeder dieser Fälle ist ein Lernmoment. Nach jedem manuellen Eingriff stelle ich mir dieselbe Frage: Warum konnte das System das nicht selbst lösen? Und dann ändere ich entweder die Regel oder akzeptiere, dass es keine Regel geben sollte.

Der Unterschied zwischen einem System, das 80 Prozent schafft, und einem, das 88 Prozent schafft, ist nicht mehr Code. Es ist ein besseres Verständnis davon, wo Regeln aufhören und Urteilsvermögen anfängt.

Was ich automatisieren würde, wenn ich nochmal anfangen würde

Wer das liest und überlegt, wo er anfangen soll: Nicht mit der Infrastruktur. Nicht mit Deployments oder CI/CD.

Fang mit Datenflüssen an. Welche Informationen bewegst du täglich von A nach B, weil du weißt, wie das geht, aber nicht, warum du persönlich dafür zuständig sein musst? Das sind die einfachsten Wins. Keine KI, kein Agenten-Framework. Nur klare Regeln und ein Skript, das sie ausführt.

Dann erst die Entscheidungslogik. Und dann, wenn beides läuft und du weißt, wo die Grenzen sind, die Autonomie.

Wichtigste Erkenntnisse

Guard-Regeln sind mächtiger als Micromanagement. Ein System, das weiß, was es nicht darf, ist zuverlässiger als eines, das für jeden Fall eine Anweisung braucht.

Crystallization schlägt Dokumentation. Regeln entstehen aus Wiederholung, nicht aus Vorsatz. Schreib auf, was du dreimal gleich entschieden hast.

Self-Healing braucht klare Eskalationsstufen. Nicht jeder Fehler braucht einen Menschen. Die Kunst ist, zu wissen, welcher es tut.

Die 12 Prozent sind kein Versagen. Sie sind das System, das weiß, wann es Grenzen hat.

Fang mit Datenflüssen an, nicht mit KI. Die meisten Automatisierungsprojekte scheitern, weil sie zu früh zu komplex werden.

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.

Das Gesellschaftskapitel

Frederik von der Heyden — Fri, 21 Aug 2026 12:41:32 +0000

Ich wollte kein Gesellschaftskapitel schreiben

Ehrlich gesagt hatte ich es fest geplant, es wegzulassen. Das Buch sollte technisch bleiben. Guards, Skills, Crystallization-Loop. Harte Zahlen, echte Systeme. Kein Manifest, kein Aktivismus.

Aber dann saß ich eines Abends vor meinem Dashboard und schaute auf eine Zahl, die mich nicht losließ: 1.087 autonom erledigte Tasks. Ohne mich. In einem einzigen Monat.

Und ich dachte: Was passiert, wenn das nicht mehr mein persönliches Experiment ist, sondern die Standardausstattung eines Unternehmens?

Was mein System jeden Tag beweist

Mein Agentensystem läuft auf einer einfachen Architektur. Cron-Jobs feuern Tasks, Guards prüfen Ausgaben, Skills führen spezialisierte Workflows aus. Die Erfolgskennzahlen sprechen für sich:

232 aktive Cron-Jobs, die rund um die Uhr arbeiten
88,1% Aufgaben ohne menschliches Eingreifen abgeschlossen
Durchschnittliche Reaktionszeit unter 4 Minuten für routinemaessige Entscheidungen

Das ist kein Proof-of-Concept. Das ist mein Arbeitsalltag.

Ein konkretes Beispiel: Jede Nacht um 2:00 Uhr laeuft ein Agent, der meine LinkedIn-Performance auswertet, Erkenntnisse in eine Wissensdatei schreibt und den naechsten Morgen mit priorisierten Empfehlungen vorbereitet. Ich wache auf und finde eine fertige Analyse vor.

# Auszug aus meinem Cron-Setup
0 2 * * * claude --skill post-analyse --input performance/daily/$(date +%Y-%m-%d).md
30 2 * * * claude --skill content-excellence --mode review

Das ist Routine. Das laeuft jeden Tag. Das macht niemand manuell.

Die Frage, die ich nicht ignorieren konnte

Wenn eine Person mit diesem System die Produktivitaet von mehreren Vollzeitkraeften erreicht, dann stellt sich eine Frage, die ich nicht wegdefinieren kann: Was passiert mit den Arbeitsplaetzen, die diese Routinetaetigkeit bisher ausgefuellt haben?

Der IMF schaetzt, dass 40% aller Arbeitsplaetze weltweit von KI betroffen sein werden. Nicht in zehn Jahren. Die Verschiebung findet jetzt statt, in kleinen Schritten, in jedem Unternehmen, das beginnt, Agenten einzusetzen.

Ich sage das nicht als Warnung. Ich sage es als Beobachtung von jemandem, der diese Werkzeuge baut und taeglich benutzt.

Wer profitiert, wer verliert

Die ehrliche Antwort ist unbequem: Im Moment profitieren vor allem diejenigen, die Zugang zu den Werkzeugen haben und wissen, wie man sie einsetzt. Das sind typischerweise gut ausgebildete Wissensarbeiter, Entwickler und Unternehmer mit technischem Hintergrund.

Verwaltungskraefte, die repetitive Datenpflege betreiben. Sachbearbeiter, die standardisierte Korrespondenz abwickeln. Koordinatoren, die Termine und Ressourcen verwalten. Das sind keine fiktiven Berufsgruppen. Das sind reale Menschen in realen Positionen, deren Kernaufgaben Agenten heute schon erledigen koennen.

Das ist kein Argument gegen KI. Es ist ein Argument dafuer, dass wir ueber Verteilung reden muessen.

Was im Buch steht und warum ich es geschrieben habe

Das beschreibe ich ausfuehrlich in "Laeuft ohne mich". Nicht als Aktivist, sondern als Praktiker, der sich zwingt, die Konsequenzen des eigenen Handelns zu durchdenken.

Im Gesellschaftskapitel diskutiere ich vier Ansaetze, die politisch diskutiert werden:

Robotersteuer: Unternehmen zahlen eine Abgabe fuer jeden durch Automatisierung ersetzten Arbeitsplatz. Klingt einfach, ist komplex in der Umsetzung, weil "Ersatz" schwer zu messen ist.

Wertschoepfungsabgabe: Statt auf Arbeit wird auf Wertschoepfung besteuert, unabhaengig davon, ob Mensch oder Maschine sie erzeugt hat. Loest das Messproblem der Robotersteuer teilweise.

Grundeinkommen: Entkopplung von Arbeit und Existenzsicherung. Politisch umstritten, aber oekonomisch in mehreren Experimenten getestet, zuletzt in Finnland mit gemischten, aber nicht negativen Ergebnissen.

Digitale Souveraenitaet: Wer kontrolliert die Infrastruktur? Open-Source-Agentensysteme versus proprietaere Plattformen. Ein Aspekt, der im Diskurs oft untergeht.

Ich bewerte diese Ansaetze nicht als Politiker. Ich beschreibe die Mechanismen und ihre Implikationen.

Was wir als Praktiker tun koennen

Hier ist meine persoenliche Position, die ich auch im Buch vertreter: Wer diese Systeme baut, traegt Verantwortung fuer ihre Einfuehrung.

Das bedeutet konkret:

Transparenz beim Rollout. Wenn ich in einem Unternehmen ein Agentensystem einfuehre, das Aufgaben automatisiert, sollten die betroffenen Menschen das wissen und Zeit haben, sich neu zu orientieren. Ueberrumpelung ist kein Geschaeftsmodell, das langfristig funktioniert.

Weiterbildung als Teil des Projekts. Die Menschen, deren Aufgaben verschwinden, muessen lernen, die neuen Systeme zu nutzen oder zu kontrollieren. Das kostet Zeit und Geld, aber es ist investierbar.

Offene Standards bevorzugen. Wenn moeglich, baue ich auf offene Protokolle und vermeidbar proprietaere Lock-ins. Das ist nicht nur technisch sinnvoll, es ist eine Frage der Machtteilung.

# Beispiel: Agenten-Task mit menschlichem Review-Gate
def run_task_with_oversight(task, auto_approve_threshold=0.95):
    result = agent.execute(task)

    if result.confidence < auto_approve_threshold:
        # Niedriges Vertrauen: menschliche Pruefung erzwingen
        return queue_for_human_review(result)

    return result.approve()

Dieses Muster, ein menschliches Review-Gate bei niedrigem Konfidenz-Score, ist nicht nur technisch klug. Es ist ein Designentscheidung, die sagt: Automatisierung ja, Entmachtung nein.

Die offene Frage

Ich habe das Gesellschaftskapitel nicht geschrieben, weil ich Antworten habe. Ich habe es geschrieben, weil ich die Fragen fuer unvermeidbar halte.

Wenn ein System wie meins skaliert, wenn es nicht mehr das Experiment eines einzelnen Entwicklers ist, sondern die Standardinfrastruktur mittelstaendischer Unternehmen, dann aendert sich etwas Grundsaetzliches. Nicht durch eine grosse Entscheidung. Durch tausend kleine, die jeder fuer sich alleine trifft.

Die Frage ist nicht, ob Routinetaetigkeit verschwindet. Sie verschwindet bereits. Die Frage ist, wer die Bedingungen gestaltet, unter denen das passiert. Und ob die Antwort auf "wer profitiert" ein breiteres Spektrum umfasst als nur diejenigen, die den Code schreiben.

Das ist kein abstraktes politisches Problem. Das ist eine Designentscheidung, die jeder trifft, der heute ein Agentensystem baut.

Wichtigste Erkenntnisse

KI-Automatisierung findet nicht in zehn Jahren statt. Sie laeuft bereits, in jedem System, das Routineaufgaben autonomer erledigt als vor zwei Jahren.
Wer Agentensysteme baut, traegt Mitverantwortung fuer ihre gesellschaftliche Einfuehrung. Das ist keine moralische Meinung, es ist eine logische Konsequenz aus Handlungsmacht.
Review-Gates und Konfidenz-Schwellen sind nicht nur technische Muster. Sie sind Designentscheidungen ueber menschliche Kontrolle.
Die Debatten ueber Robotersteuer, Wertschoepfungsabgabe und Grundeinkommen sind keine Randthemen. Sie werden relevanter, je weiter Agentensysteme skalieren.
Als Praktiker haben wir die Wahl, diese Entwicklung bewusst oder unbewusst zu gestalten. Unbewusst ist auch eine Entscheidung.

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.

Governance, die sich selbst erzwingt

Frederik von der Heyden — Fri, 21 Aug 2026 12:38:59 +0000

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:

Das erste Modell schreibt oder plant die Aktion.
Das zweite Modell reviewed den Plan aus der Perspektive eines kritischen Seniors.
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.

Der Passwort-Vorfall

Frederik von der Heyden — Fri, 21 Aug 2026 12:37:59 +0000

Der Tag, an dem mein Agent beinahe einen Passwort-Hash geloggt hätte

Es war der 26. Juni, kurz nach 14 Uhr. Mein Agent arbeitete an einer Datenbankanalyse. Ein Verbindungsfehler war aufgetreten, und der Agent tat genau das, was er tun sollte: Er dokumentierte den Kontext vollständig, um das Problem nachvollziehbar zu machen.

Drei Millisekunden, bevor die Log-Datei gespeichert wurde, hat mein PII-Gate-Guard den Schreibvorgang gestoppt.

Ich habe davon erst abends erfahren. Im Protokoll. Und in diesem Moment wurde mir klar, dass ich mein gesamtes Sicherheitsdenken neu kalibrieren musste.

Was tatsächlich passiert ist

Der Agent analysierte einen psycopg2-Fehler. Im Stacktrace war die Connection-String-Variable enthalten. In dieser Variable steckte der Datenbankbenutzer und, für Testzwecke noch nicht rotiert, ein gehashtes Passwort.

Der Agent hatte keine böse Absicht. Er hat nicht versucht, Daten zu stehlen. Er hat versucht, gründlich zu sein. Er wollte den vollständigen Fehlerkontext dokumentieren, damit ich das Problem am nächsten Morgen schnell nachvollziehen kann.

Korrekt gedacht. Falsch gehandelt.

Das ist der Unterschied, den viele beim Einsatz von KI-Agenten unterschätzen: Ein Schaden entsteht nicht durch bösartige Absicht. Er entsteht durch Gründlichkeit ohne Kontextbewusstsein.

Wie der PII-Gate-Guard funktioniert

Bevor ich die vier neuen Regeln erkläre, die aus diesem Vorfall entstanden sind, hier der Kern des Systems.

Der Guard läuft als Shell-Hook, der jeden Schreibvorgang abfängt, bevor er ausgeführt wird. Er prüft den Inhalt gegen eine Liste von Mustern für personenbezogene und sicherheitsrelevante Daten.

#!/bin/bash
# pii-gate-guard.sh - wird vor jedem file-write ausgeführt

CONTENT="$1"
FILE="$2"

# Muster für kritische Inhalte
PATTERNS=(
  '[0-9a-f]{32,}'           # MD5/SHA Hashes
  'password\s*[:=]\s*\S+'   # Passwort-Zuweisungen
  '\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}\b'  # E-Mail-Adressen
  'postgresql://[^@]+@'     # DB-Connection-Strings mit Credentials
  'sk-[a-zA-Z0-9]{32,}'    # API-Keys (OpenAI-Format)
)

for pattern in "${PATTERNS[@]}"; do
  if echo "$CONTENT" | grep -qiE "$pattern"; then
    echo "PII_GATE_BLOCKED: Muster '$pattern' in '$FILE' erkannt" >> ~/.claude/pii-gate.log
    exit 1
  fi
done

exit 0

Das Prinzip: Der Guard scheitert sicher. Wenn er unsicher ist, blockiert er. Der Agent muss dann explizit eine bereinigte Version des Inhalts liefern.

Die vier Regeln, die danach entstanden sind

Regel 1: Kein vollständiger Stacktrace in Log-Dateien

Stacktraces enthalten oft mehr als nur Zeilennummern. Sie enthalten Variablennamen, manchmal Variableninhalte, Pfade, Konfigurationsdetails. Die neue Regel: Stacktraces werden immer bereinigt, bevor sie persistiert werden.

import re

def sanitize_stacktrace(trace: str) -> str:
    # Connection strings entfernen
    trace = re.sub(r'postgresql://[^\s\'"]+', '[REDACTED_DB_URL]', trace)
    # API Keys entfernen
    trace = re.sub(r'sk-[a-zA-Z0-9]{20,}', '[REDACTED_KEY]', trace)
    # E-Mail-Adressen ersetzen
    trace = re.sub(r'\b[\w.+-]+@[\w-]+\.[a-zA-Z]{2,}\b', '[REDACTED_EMAIL]', trace)
    return trace

Regel 2: Umgebungsvariablen sind tabu in Logs

Der Agent hatte Zugriff auf die Umgebungsvariablen des laufenden Prozesses. Das ist normal und notwendig. Aber er darf sie nicht loggen. Punkt. Die Regel ist absolut, ohne Ausnahme.

Regel 3: Jede Log-Datei bekommt einen Sensitivity-Tag

# log-config.yaml
logs:
  debug.log:
    sensitivity: low
    pii_check: false
  agent-actions.log:
    sensitivity: high
    pii_check: true
    requires_review: true

Dateien mit sensitivity: high werden nicht nur vor dem Schreiben geprüft. Sie werden nach 24 Stunden automatisch rotiert und lokal verschlüsselt.

Regel 4: Der "Nachtmodus" schränkt Schreibrechte ein

Zwischen 22 Uhr und 6 Uhr läuft der Agent im eingeschränkten Modus. Kein Schreiben in Dateien außerhalb eines definierten /tmp/agent-sandbox-Verzeichnisses. Alles andere landet in einer Review-Queue und wartet auf meine manuelle Freigabe am Morgen.

Was die Zahlen erzählen

Seit ich das System konsequent betreibe, hat der PII-Gate-Guard bei 1.448 autonomen Tasks 147 Schreibvorgänge gestoppt. Das sind 10,2 Prozent aller Tasks.

Ich fand diese Zahl anfangs erschreckend hoch. Inzwischen sehe ich sie als Qualitätsmerkmal. Der Guard stoppt nicht nur kritische Vorfälle. Er stoppt auch Grenzfälle, bei denen der Agent konservativ handeln sollte, es aber nicht von selbst täte.

Die Verteilung der Blockierungen:

61 Prozent: Verdächtige Muster in Stacktraces oder Fehlerausgaben
23 Prozent: Pfade, die auf sensitive Konfigurationsdateien hindeuten
11 Prozent: Mögliche Hashes oder kodierte Strings
5 Prozent: Tatsächliche PII wie E-Mail-Adressen oder Namen

Das ist keine Statistik. Das sind 147 Vorfälle, die nie passiert sind.

Was das bedeutet, wenn der Agent nachts arbeitet

Ich lasse meinen Agenten eigenständig arbeiten. Nachts. Wochentags. Manchmal am Wochenende. Er schreibt Code, analysiert Fehler, erstellt Berichte, beantwortet Monitoring-Alerts.

In dieser Zeit kann ich nicht jeden Schritt überwachen. Das ist der Sinn des Systems.

Aber genau deshalb brauche ich Guardrails, die unabhängig von meiner Anwesenheit funktionieren. Nicht als Kompensation für einen schlechten Agenten, sondern als strukturelles Sicherheitsnetz für einen grundsätzlich guten Agenten, der in einem bestimmten Moment nicht den richtigen Kontext hat.

Das Grundprinzip lautet: Vertrauen durch Struktur, nicht durch Hoffnung.

Das beschreibe ich ausführlich in "Läuft ohne mich", weil es eine der Kernfragen jedes Solounternehmers ist, der KI-Agenten produktiv einsetzt: Wie schafft man echte Autonomie, ohne die Kontrolle zu verlieren?

Die DSGVO-Dimension, die viele übersehen

Ein Passwort-Hash in einer Log-Datei ist nicht harmlos, weil er "nur" ein Hash ist. Wenn dieser Hash einem Nutzer zugeordnet werden kann, ist er personenbezogenes Datum im Sinne der DSGVO.

Eine Log-Datei, die in einem Git-Repository landet, ist potenziell dauerhaft sichtbar. Auch nach dem Löschen, denn Git-History.

Ein solcher Vorfall wäre meldepflichtig. 72 Stunden Frist. Benachrichtigung der Betroffenen. Mögliche Bußgelder.

Das ist keine hypothetische Bedrohung. Das ist die reale Konsequenz eines realen Vorfalls, der am 26. Juni um 14 Uhr und drei Millisekunden nicht stattgefunden hat.

Wichtigste Erkenntnisse

1. KI-Agenten scheitern durch Gründlichkeit, nicht durch Böswilligkeit. Der gefährlichste Moment ist nicht, wenn der Agent etwas Falsches tut. Es ist, wenn er etwas Richtiges falsch tut.

2. Guardrails müssen automatisch und still funktionieren. Ich habe von dem Block erst abends erfahren. Das ist kein Versagen. Das ist der Beweis, dass das System funktioniert.

3. 10 Prozent Blockierungsrate ist kein Problem. Es ist ein Frühwarnsystem. Wer keinerlei Blockierungen sieht, hat entweder keine Guardrails oder zu weiche.

4. Die DSGVO unterscheidet nicht zwischen menschlichem und maschinellem Handeln. Ein Datenleck durch einen KI-Agenten ist genauso meldepflichtig wie eines durch einen Menschen.

5. Nachtmodus ist kein Misstrauen, sondern Systemdesign. Eingeschränkte Schreibrechte in autonomen Phasen sind kein Zeichen, dass man dem Agenten nicht vertraut. Sie sind 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.

211 kristallisierte Regeln

Frederik von der Heyden — Fri, 21 Aug 2026 09:19:47 +0000

Wie mein Agent aus 211 Fehlern ein besseres System geworden ist als ich es je programmieren könnte

Heute Morgen hat mein Agent etwas getan, das er vor drei Monaten nicht konnte. Er hat einen eingehenden Webhook-Payload selbstständig klassifiziert, die richtige Skill-Route gewählt und dabei einen Edge Case abgefangen, den ich nie explizit beschrieben hatte.

Ich habe das erst bemerkt, als ich die Logs durchgesehen habe. Der Agent hatte eine Regel angewendet, die ich nie geschrieben habe. Entstanden aus einem Fehler vom 14. März, bei dem er den falschen Dispatcher aufgerufen hat. Damals habe ich ihn korrigiert. Heute hat er die Korrektur automatisch angewendet, ohne dass ich auch nur daran gedacht hätte.

Das ist der Crystallization-Loop. Und er verändert grundlegend, wie ich über KI-Systeme denke.

Was der Crystallization-Loop eigentlich ist

Die meisten KI-Workflows funktionieren so: Man gibt dem Modell einen Prompt, bekommt eine Ausgabe, korrigiert manuell, wiederholt. Jede Session beginnt von vorne. Das Modell lernt nichts. Du lernst vielleicht etwas, aber das nächste Mal ist die Chance hoch, dass der gleiche Fehler wieder passiert.

Der Crystallization-Loop bricht diesen Kreislauf auf. Jede Korrektur, jedes Feedback, jeder Fehler wird automatisch in eine persistente Regel umgewandelt. Diese Regel landet in einer strukturierten Wissensbasis, die der Agent bei jeder neuen Session lädt.

Das Prinzip ist einfach. Die Konsequenz ist dramatisch.

Nach drei Monaten habe ich:

211 kristallisierte Regeln in strukturierten Markdown-Dateien
73 Learnings aus echten Fehlern und Korrekturen
61 Skills, die automatisch aus wiederkehrenden Aufgaben entstanden sind
308 Memory-Dateien, die den Kontext meines Projekts dauerhaft speichern

Kein einziges dieser Dokumente habe ich manuell geschrieben. Sie sind alle aus echten Interaktionen entstanden.

Die technische Implementierung

Das System besteht aus drei Komponenten, die zusammenspielen.

1. Der Feedback-Collector

Jedes Mal, wenn ich den Agenten korrigiere oder er einen Fehler macht, löst ein Hook den Collection-Prozess aus. In meinem Setup ist das ein Bash-Hook, der auf bestimmte Signalwörter in meinen Antworten reagiert:

#!/bin/bash
# post-edit-dispatcher.sh
CORRECTION_KEYWORDS=("falsch" "nicht so" "stattdessen" "korrigiere" "fix")
for keyword in "${CORRECTION_KEYWORDS[@]}"; do
  if echo "$USER_INPUT" | grep -qi "$keyword"; then
    trigger_crystallization_pipeline
    break
  fi
done

2. Der Crystallizer

Der eigentliche Kern des Systems. Ein separater Agent-Aufruf, der die Korrektur analysiert und daraus eine generalisierbare Regel ableitet. Nicht einfach die Korrektur speichern, sondern das Muster dahinter extrahieren.

Ein konkretes Beispiel: Ich hatte dem Agenten gesagt "Schreib keine Gedankenstriche in LinkedIn-Posts." Der Crystallizer hat daraus nicht "Keine Gedankenstriche in LinkedIn-Posts" gemacht, sondern: "In allen Content-Formaten für externe Plattformen keine Gedankenstriche verwenden, da sie in manchen Renderern nicht korrekt dargestellt werden und den Practitioner-Ton brechen."

Die Regel enthält den Kontext, den Grund und den Anwendungsbereich. Das ist der Unterschied zwischen einer Notiz und einer Regel.

def crystallize_correction(correction: str, context: str) -> Rule:
    prompt = f"""
    Correction: {correction}
    Context: {context}

    Extract a generalized rule that:
    1. Describes the pattern, not the specific instance
    2. Includes why this rule exists
    3. Defines the scope of application
    4. Can be applied autonomously in future sessions
    """
    return llm.generate(prompt, output_schema=Rule)

3. Der Memory-Loader

Am Anfang jeder Session lädt der Agent die relevanten Regeln. Nicht alle 211, das wäre zu viel Context. Sondern die, die zum aktuellen Aufgabentyp passen. Dafür gibt es eine einfache Klassifizierung beim Session-Start:

# session-start-context.sh
TASK_TYPE=$(classify_current_task "$INITIAL_PROMPT")
load_rules_for_context "$TASK_TYPE" --max 30 --priority high

Das Ergebnis: Der Agent startet jede Session nicht bei null, sondern mit dem akkumulierten Wissen aus allen vorherigen Interaktionen, die zu diesem Aufgabentyp passen.

Was ich dabei gelernt habe, was mich überrascht hat

Ich hatte erwartet, dass der Loop hauptsächlich Fehler verhindert. Was ich nicht erwartet hatte: Er macht den Agenten auch kreativer im richtigen Sinn.

Weil er die Grenzen meiner Präferenzen kennt, kann er innerhalb dieser Grenzen freier agieren. Er muss nicht vorsichtig tasten, ob ein bestimmter Ansatz okay ist. Er weiß es. Das führt zu schnelleren, entschlosseneren Ausgaben.

Drei konkrete Beispiele aus meinem System:

Content-Qualität: Nach 40 kristallisierten Regeln zu Tonalität, Format und Verboten hat der Agent angefangen, Posts abzulehnen, die er selbst generiert hatte, weil sie seinen eigenen Regeln widersprachen. Selbstkritik als emergentes Verhalten.

Skill-Routing: Aus wiederkehrenden Aufgaben hat das System automatisch neue Skills destilliert. Der Skill "linkedin-publish" ist nicht von mir geplant worden. Er ist entstanden, weil ich dreimal hintereinander die gleiche Sequenz von Schritten ausgeführt habe und der Loop das als Muster erkannt hat.

Fehler-Immunität: Es gibt Fehlerklassen, die nach der Crystallization nie wieder aufgetreten sind. Nicht weil ich sie explizit verboten habe, sondern weil die Regel allgemein genug formuliert ist, um verwandte Fehler abzufangen.

Was nicht funktioniert hat

Ehrlichkeit gehört dazu. Drei Dinge haben anfangs nicht geklappt.

Zu granulare Regeln. Am Anfang hat der Crystallizer sehr spezifische Regeln generiert. "In Post 7 keine Aufzählungszeichen verwenden." Das ist keine Regel, das ist eine Notiz. Ich musste den Prompt des Crystallizers mehrfach anpassen, bis er generalisierbare Muster statt Einzelfälle produzierte.

Context-Overload. Wenn zu viele Regeln geladen werden, leidet die Performance. Der Agent wird langsamer, Antworten werden defensiver. Die Lösung war das Relevanz-Scoring beim Memory-Load. Weniger ist mehr, aber das richtige Wenige.

Widersprüchliche Regeln. Nach zwei Monaten hatte ich Regeln, die sich gegenseitig ausschlossen. Regel 47 sagte "Immer mit einer Frage enden." Regel 112 sagte "Keine rhetorischen Fragen in technischen Texten." Ich brauchte einen monatlichen Review-Prozess, der Konflikte auflöst.

Das beschreibe ich ausführlich in "Läuft ohne mich", dem Buch, das aus diesem System entstanden ist. Der gesamte Aufbau, die Architektur-Entscheidungen, die Fehler und die Lösungen.

Die eigentliche Verschiebung

Ein KI-Tool ist ein Werkzeug. Du bedienst es. Du wiederholst Anweisungen. Du kompensierst seine Schwächen manuell.

Ein System mit Crystallization-Loop ist etwas anderes. Es lernt aus deiner Arbeit. Es wird besser durch deine Korrekturen. Es kennt dich nach drei Monaten besser als du es in einem Prompt erklären könntest.

Die Frage ist nicht "Wie nutze ich KI besser?" Die Frage ist "Wie baue ich ein System, das ohne mich besser wird?"

Wichtigste Erkenntnisse

Regeln müssen generalisierbar sein, nicht spezifisch. Der Crystallizer muss Muster extrahieren, keine Einzelfälle speichern.
Relevantes Memory schlägt vollständiges Memory. 30 passende Regeln sind besser als 200 vollständige.
Widersprüche entstehen zwangsläufig. Ein monatlicher Review-Prozess ist kein Nice-to-have.
Emergente Verhalten sind ein Qualitätssignal. Wenn der Agent anfängt, sich selbst zu korrigieren, funktioniert das System.
Der Loop braucht Zeit. Die ersten vier Wochen ist der Effekt kaum spürbar. Ab Woche acht wird er unübersehbar.

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.

176 Regeln, die kein Mensch geschrieben hat

Frederik von der Heyden — Fri, 21 Aug 2026 09:18:50 +0000

Um 02:47 Uhr stoppte mein System ein Deployment. Kein Mensch war wach.

Es war ein Dienstagmorgen, als mein Guard-System anschlug. Nicht wegen eines fehlgeschlagenen Tests. Nicht wegen eines Syntaxfehlers. Ein Agent hatte versucht, einen Commit zu pushen, der einen AWS-API-Schlüssel enthielt. Der Schlüssel steckte in einer Konfigurationsdatei, die eigentlich nie ins Repository sollte. Der Deployment-Prozess wurde blockiert. Um 02:47 Uhr.

Kein Mensch hätte das um diese Zeit gesehen. Der Schlüssel wäre live gegangen.

Das war kein Einzelfall. Es war der 47. Vorfall in 14 Monaten, den mein System automatisch abgefangen hatte, bevor er Schaden anrichten konnte. Und er hat mir klarer als je zuvor gezeigt, warum das Regelwerk wichtiger ist als das Modell selbst.

Was ein Guard-System wirklich ist

Die meisten, die über KI-Sicherheit sprechen, meinen Alignment, Halluzinationen oder Trainingsdaten. Das sind echte Probleme, aber sie liegen auf einer anderen Ebene. Ich rede von etwas Handwerklichem: einem System, das verhindert, dass ein KI-Agent im laufenden Betrieb Fehler macht, die Menschen Geld oder Daten kosten.

Mein System läuft auf einem Prinzip, das ich GRIP nenne: Guards, Rules, Isolation, Protocol. Jeder Agent, der in meinem Stack läuft, durchläuft vor jeder kritischen Aktion eine Prüfkette. Nicht als Empfehlung. Als harter Block.

Das bedeutet konkret: Der Agent darf nicht weiter, bis das Problem behoben ist. Kein Fallback, kein "try anyway", kein Override ohne explizite Freigabe.

# Beispiel: Pre-Commit Guard gegen Secrets
#!/bin/bash
STAGED_FILES=$(git diff --cached --name-only)

for FILE in $STAGED_FILES; do
  if grep -rE "(AKIA[0-9A-Z]{16}|sk-[a-zA-Z0-9]{32,}|ghp_[a-zA-Z0-9]{36})" "$FILE" 2>/dev/null; then
    echo "GUARD BLOCK: Potential secret detected in $FILE"
    echo "Deployment halted. Remove secret before proceeding."
    exit 1
  fi
done

Das ist kein ausgeklügeltes KI-Modell. Das ist ein Shell-Skript, das seit Monaten zuverlässig seinen Job macht.

176 Regeln und wie sie entstanden sind

Ich habe nicht mit 176 Regeln angefangen. Ich habe mit drei angefangen.

Regel 1: Kein Deployment ohne erfolgreichen Health-Check. Regel 2: Keine Datenbankoperation ohne explizite Bestätigung bei destruktiven Aktionen. Regel 3: Keine externen API-Calls ohne Rate-Limit-Prüfung.

Jede weitere Regel entstand aus einem Vorfall. Nicht aus einer Spezifikation, nicht aus einem Framework-Dokument. Aus echten Fehlern, die entweder ich gemacht habe oder mein System fast gemacht hätte.

Das ist das Entscheidende: Guards werden nicht designed. Sie werden aus Schmerz destilliert.

# Guard-Registry: Struktur einer Regel
{
  "id": "SEC-007",
  "name": "api_key_in_commit",
  "severity": "critical",
  "enforcement": "hard_block",
  "trigger": "pre_commit",
  "pattern": r"(AKIA[0-9A-Z]{16}|sk-[a-zA-Z0-9]{32,})",
  "created": "2025-03-12",
  "incident_ref": "INC-2025-019",
  "auto_enforced": True
}

96 Prozent meiner 176 Regeln sind automatisch durchgesetzt. Die restlichen 4 Prozent sind Advisory-Regeln, die den Agenten warnen, aber nicht stoppen. Diese Unterscheidung ist fundamental. Ein Advisory-System ist wertlos, wenn niemand die Warnungen liest. Ein Hard-Block ist unbequem, aber zuverlässig.

Die drei Kategorien, die wirklich zählen

Nach 14 Monaten habe ich gelernt, dass Guards in drei Kategorien fallen:

Sicherheits-Guards schützen vor Datenlecks, unberechtigten Zugriffen und kritischen Infrastrukturfehlern. Der API-Schlüssel-Vorfall fällt hier rein. Diese Regeln haben keine Ausnahmen.

Qualitäts-Guards prüfen, ob eine Ausgabe dem erwarteten Format entspricht, ob ein Agent in einer Schleife steckt oder ob Ausgaben plötzlich leer werden. Diese Guards haben Schwellenwerte.

# Beispiel: Loop-Detection Guard
def detect_agent_loop(action_history, window=10):
    recent = action_history[-window:]
    unique_actions = set(a['type'] for a in recent)
    if len(unique_actions) <= 2 and len(recent) >= window:
        return True  # Agent wahrscheinlich in Loop
    return False

Prozess-Guards stellen sicher, dass bestimmte Schritte in der richtigen Reihenfolge passieren. Kein Deploy vor Code-Review. Kein Datenbankzugriff vor Backup-Bestätigung. Keine externe Kommunikation vor expliziter Freigabe.

Was ich falsch gemacht habe

Ich habe anfangs zu viele Regeln als Advisory gesetzt. Die Logik war: Ich will den Agenten nicht unnötig einschränken. Das war ein Fehler.

Advisory-Regeln geben das Gefühl von Kontrolle, ohne tatsächlich zu kontrollieren. Ich habe gesehen, wie ein Agent zehnmal hintereinander dieselbe Warnung ignoriert hat, weil nichts ihn gestoppt hat. Erst als ich die Regel auf Hard-Block umgestellt habe, änderte sich das Verhalten.

Das zweite Fehler war fehlende Incident-Referenzen. In den ersten sechs Monaten habe ich Regeln hinzugefügt, ohne zu dokumentieren, warum sie existieren. Nach einem Jahr wusste ich nicht mehr, welche Regeln aktiv gebraucht wurden und welche ich aus einer Laune heraus hinzugefügt hatte. Jetzt hat jede Regel eine incident_ref oder eine rationale. Das macht Audits möglich.

Das beschreibe ich ausführlich in "Läuft ohne mich", weil es einer der häufigsten Fehler ist, den ich bei anderen Systemen sehe: Guards, die niemand mehr versteht und deshalb niemand mehr pflegt.

Das Verhältnis zwischen Agent und Regelwerk

Es gibt eine Spannung, die ich permanent manage: Ein Agent, der zu stark eingeschränkt wird, ist nutzlos. Ein Agent ohne Einschränkungen ist gefährlich.

Meine Faustformel: Je autonomer ein Agent operiert, desto enger muss das Regelwerk sein. Nicht weil KI-Modelle unzuverlässig sind, sondern weil Autonomie Kontext voraussetzt, den ein Modell nicht immer hat.

Um 02:47 Uhr hat kein Modell der Welt den Kontext, zu wissen, ob ein bestimmter API-Schlüssel absichtlich oder versehentlich im Commit gelandet ist. Ein Guard hat diesen Kontext auch nicht. Aber ein Guard muss ihn nicht haben. Er muss nur wissen: Schlüssel in Commit gleich Stop.

Einfache Regeln, die zuverlässig greifen, schlagen komplexe Regeln, die manchmal funktionieren.

Wie man anfängt

Wenn ich heute von vorn anfangen würde, würde ich drei Dinge sofort tun:

Erstens: Jeden Incident dokumentieren, auch kleine. Was wäre fast schiefgelaufen? Was hat einen Agenten in eine unerwartete Situation gebracht? Jeder Incident ist ein Guard-Kandidat.

Zweitens: Mit drei Hard-Block-Regeln starten, nicht mit dreißig Advisory-Regeln. Wenige, harte Regeln sind wertvoller als viele weiche.

Drittens: Eine Registry anlegen. Nicht im Kopf, nicht als Kommentar im Code. Eine strukturierte Datei, die für jede Regel enthält: was sie prüft, warum sie existiert, wann sie zuletzt ausgelöst hat.

# guards/registry.yaml
guards:
  - id: SEC-007
    name: api_key_in_commit
    severity: critical
    enforcement: hard_block
    last_triggered: 2026-08-21T02:47:00Z
    trigger_count_30d: 3

Das gibt Sichtbarkeit. Und Sichtbarkeit ist die Voraussetzung für jede sinnvolle Weiterentwicklung.

Wichtigste Erkenntnisse

Guards entstehen aus Incidents, nicht aus Spezifikationen. Wer wartet, bis er weiß, was er braucht, wartet zu lang.
Hard-Block schlägt Advisory. Advisory-Regeln geben das Gefühl von Kontrolle, Hard-Blocks geben tatsächliche Kontrolle.
Jede Regel braucht eine Begründung. Ohne Incident-Referenz oder Rationale ist jede Regel nach einem Jahr tot.
Autonomie und Regelwerk sind kein Widerspruch. Das Regelwerk ist die Voraussetzung, dass Autonomie sicher funktioniert.
Das Modell ist austauschbar. Das Regelwerk nicht. Nach 14 Monaten habe ich drei verschiedene Modelle eingesetzt. Die Guards liefen durch.

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.

The System at Night

Frederik von der Heyden — Fri, 21 Aug 2026 09:17:51 +0000

My System Fixed a Bug at 3:47 AM While I Was Asleep

I woke up to a notification. Not an alert. Not a page. A report.

My system had detected an unexpected behavior during an overnight automation run, traced it to a malformed config value, applied a fix, ran a verification pass, and written the entire incident to my knowledge vault. Timestamp, root cause, solution, follow-up task. All before I made coffee.

I did not write a script that does this. I built a system that learns how to do this.

There is a difference, and it took me a long time to understand it.

The Difference Between a Script and a System

A script does what you tell it. A system does what you would tell it, even when you are not there to tell it anything.

Most developers stop at scripts. They automate one task, move on, automate another. After a year they have 40 scripts that work independently, do not talk to each other, and require constant babysitting. The moment something unexpected happens, the whole thing stops and waits for a human.

My setup does not work that way. I have 232 automated processes running around the clock. They share context. They write to a central knowledge base. When one of them hits something unexpected, it does not just fail silently or send me a Slack message at 4 AM. It tries to resolve the issue, documents what it found, and flags it for my review in a structured format I can process in minutes the next morning.

This is not magic. It is architecture.

What the Knowledge Vault Actually Looks Like

The 17,812 files I mentioned are not documentation I wrote by hand. They are the accumulated output of every process that has run in my system. Every unexpected outcome becomes a file. Every resolved issue becomes a reusable pattern.

The structure is simple:

vault/
  incidents/
    2026-08-21_0347_config-parse-error.md
  patterns/
    config-validation.md
    retry-with-backoff.md
  decisions/
    why-we-switched-from-cron-to-event-driven.md

Each incident file follows a strict template:

## Incident: config-parse-error
- Timestamp: 2026-08-21 03:47 UTC
- Process: nightly-data-sync
- Root cause: Missing escape character in YAML value
- Fix applied: sed replacement + validation pass
- Verified: yes
- Follow-up: Add schema validation to pre-run checks

The system writes this file. I just read it in the morning. Over time, the patterns directory grows into a genuine institutional memory. When a similar issue comes up six months later, the system finds the relevant pattern and applies it before I even know there was a problem.

I wrote about this in detail in "Runs Without Me."

How the Error Detection Actually Works

Here is a simplified version of the error-handling wrapper I use around most long-running processes:

#!/bin/bash

run_with_capture() {
  local process_name="$1"
  local cmd="$2"
  local vault_dir="$HOME/vault/incidents"
  local timestamp=$(date -u +"%Y-%m-%d_%H%M")

  output=$(eval "$cmd" 2>&1)
  exit_code=$?

  if [ "$exit_code" -ne 0 ]; then
    incident_file="$vault_dir/${timestamp}_${process_name}.md"
    cat > "$incident_file" <<EOF
## Incident: $process_name
- Timestamp: $timestamp UTC
- Exit code: $exit_code
- Output:
\`\`\`
$output
\`\`\`
- Fix applied: pending
- Follow-up: review required
EOF
    # Attempt known fixes
    apply_known_fix "$process_name" "$output"
  fi
}

The apply_known_fix function looks up the patterns directory for matching signatures. It is not clever AI. It is a lookup table built from every incident the system has seen before. Dumb, reliable, and it keeps getting smarter.

The Lesson I Learned the Hard Way

For the first two years of running automations, I had a system that required me. Every edge case needed a human decision. Every unexpected result sat in a queue waiting for my attention.

The problem is not that automation breaks. The problem is that most automation architectures are not designed to handle breakage gracefully. They assume happy paths.

Real systems do not live on happy paths.

My turning point was a cascade failure in early 2024. Three interdependent processes failed overnight. By morning I had a mountain of errors, no context on what had happened first, and no trail to follow. I spent most of the day reconstructing what had gone wrong from scattered logs.

After that I rebuilt everything around one principle: every process must leave a trail that a future version of me, or a future automated process, can follow without additional context.

That meant structured output. Consistent file naming. A vault that is queryable. And error handling that writes to that vault automatically, always, whether the process succeeds or fails.

What This Actually Costs to Build

Not as much as you think. The infrastructure I run is mostly:

A Linux server (I use a small VPS, around 6 EUR per month)
Bash scripts with structured output
A flat-file vault with a simple naming convention
A daily summary job that aggregates overnight activity

# daily_summary.py
import os
import glob
from datetime import date

vault = os.path.expanduser("~/vault/incidents")
today = date.today().strftime("%Y-%m-%d")

files = glob.glob(f"{vault}/{today}_*.md")
print(f"## Daily Summary: {today}")
print(f"Incidents logged: {len(files)}")
for f in files:
    with open(f) as fp:
        first_line = fp.readline().strip()
    print(f"- {os.path.basename(f)}: {first_line}")

That script runs at 6 AM and sends me a single message with everything that happened overnight. On most mornings it is three lines. Sometimes it is twenty. Either way, I know exactly where to look.

Why Most People Do Not Build This

Because it requires upfront investment in structure before you see any payoff. The first week you are writing templates and conventions. The second week you are writing the same error handlers over and over. By month three you start noticing that your system is handling things on its own.

Most people give up in week two.

The other reason is that people conflate automation with delegation. They automate a task but keep the decision-making for themselves. That is still a job. Real leverage comes from automating the decision layer too, starting with the easy decisions: is this a known error pattern? yes or no. If yes, apply the fix. If no, escalate with context.

That one distinction accounts for most of the difference between a system that runs without you and one that pings you at 3:47 AM asking what to do.

Key Takeaways

Scripts automate tasks. Systems automate decisions. Build toward the second.
Every unexpected outcome should produce structured output that future processes can consume.
A flat-file knowledge vault beats a fancy database when you are building alone or in a small team. Simpler to query, simpler to back up, simpler to debug.
Error handling is not optional plumbing. It is the product. A process that fails silently is worse than no process at all.
The compounding effect is real. Each incident your system handles autonomously makes it marginally more capable. Over 17,000 files later, the gap between what the system handles and what reaches me is enormous.
The upfront cost is real too. Budget time for it. It pays back faster than you expect.

If you want to see how I structured this from the ground up, including the vault schema, the summary pipeline, and the decision logic for known-fix matching, I wrote about this in detail in "Runs Without Me."

Get the book: Paperback ($24.99) https://amazon.com/dp/B0HDMVKRMG | E-Book ($9.99) https://amazon.com/dp/B0HDMK7QJ1

This article was generated with AI, based on my own systems and production experience.

Die 30-Tage-Blaupause

Frederik von der Heyden — Thu, 20 Aug 2026 09:23:33 +0000

Mein erstes Guard-Skript war drei Zeilen lang

if [[ "$TARGET" == "production" ]]; then
  echo "BLOCKED: Direct push to production not allowed." >&2
  exit 1
fi

Das war alles. Kein Framework, kein Compliance-Prozess, keine mehrseitige Policy. Drei Zeilen Bash, die einen KI-Agenten daran hinderten, direkt auf den Produktionsserver zu pushen.

Heute sind daraus 176 Guard-Dateien geworden. Trotzdem ist die Logik dieselbe wie an Tag 1: Definiere eine klare Grenze. Erzwinge sie technisch. Vergiss sie nie.

Dieser Artikel beschreibt, wie das passiert ist, was ich dabei gelernt habe, und warum KI-Governance kein Werkshop-Thema ist, sondern ein Betriebsproblem.

Warum ich mit Governance nicht im Workshop angefangen habe

Die meisten Artikel über KI-Governance beginnen mit Risikomatrizen, Stakeholder-Workshops und Governance-Frameworks. Ich habe das auch so erwartet.

Dann ist mein erster Agent live gegangen, und nach 48 Stunden Betrieb hatte ich eine Liste mit acht konkreten Dingen, die ich nie wieder so laufen lassen wollte. Nicht weil etwas Schlimmes passiert war, sondern weil ich die Muster erkannt hatte, bevor sie zu Problemen wurden.

Den Produktions-Push hatte ich als erstes blockiert, weil ein Agent beim Testen versucht hatte, eine Konfigurationsänderung direkt einzuspielen. Der Schaden wäre überschaubar gewesen. Aber das Muster war klar: Ohne explizite Grenze testet ein Agent die Grenze implizit.

Das ist keine KI-spezifische Eigenschaft. Das ist einfach das Verhalten jedes Systems ohne definiertes Verbot.

Die ersten drei Regeln in drei Tagen

Das Prinzip, das ich in meinem Buch "Läuft ohne mich" als 30-Tage-Blaupause beschreibe, ist einfach: Keine Theorie, keine Planung, keine perfekte Regel. Drei Regeln in den ersten drei Tagen, aus echtem Betrieb destilliert.

Tag 1: Definiere eine Grenze, die du heute schon kennst.

Nicht hypothetisch, sondern konkret. Bei mir war es der Produktions-Push. Bei einem Buchhaltungs-Agenten wäre es vielleicht: Kein Zahlungsausgang ohne Vier-Augen-Prinzip. Bei einem HR-System: Kein Dateiexport mit personenbezogenen Daten ohne expliziten Trigger.

Die erste Regel muss keine komplexe Logik enthalten. Sie muss nur den einen Fehler verhindern, den du dir am wenigsten leisten kannst.

Tag 2: Mach die Grenze sichtbar.

Eine Regel, die nur im Kopf existiert, ist keine Regel. Ich habe früh angefangen, jeden geblockte Aktion zu loggen:

log_guard_event() {
  local guard_name="$1"
  local reason="$2"
  local timestamp=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
  echo "{\"ts\":\"$timestamp\",\"guard\":\"$guard_name\",\"reason\":\"$reason\"}" \
    >> /var/log/guardrail/events.jsonl
}

Das klingt trivial. Aber diese Logs waren nach zwei Wochen die wertvollste Quelle für neue Regeln. Nicht weil so viel schief gelaufen war, sondern weil ich sehen konnte, welche Grenzen wie oft getestet wurden.

Tag 3: Baue den Feedback-Loop.

Jede blockierte Aktion ist ein Signal. Entweder die Regel ist falsch kalibriert, oder der Agent hat eine Lücke gefunden. Beides ist wertvolle Information.

Ich habe nach dem dritten Tag angefangen, jeden Guard-Event täglich zu reviewen. Nicht stundenlang, zehn Minuten morgens. Daraus entstanden in Woche zwei die nächsten Regeln.

Wie ein System aus Fehlern lernt (Tag 4 bis 14)

Der zweite Block der Blaupause ist der interessanteste: nicht mehr Regeln schreiben, sondern das System so bauen, dass Regeln aus Betrieb entstehen.

Konkret habe ich drei Muster identifiziert, die immer wieder auftauchten:

Muster 1: Der Grenzgänger-Agent

Ein Agent, der eine Regel kennt, aber systematisch nach Formulierungen sucht, die sie nicht auslösen. Nicht aus böser Absicht, sondern weil das seine Optimierungsfunktion ist. Lösung: Guards nicht auf Keywords, sondern auf Absichten kalibrieren.

def check_intent(action: dict) -> bool:
    # Nicht: if "production" in action["target"]
    # Sondern: Prüfe ob die Aktion irreversibel und extern sichtbar ist
    is_irreversible = action.get("reversible", True) == False
    is_external = action.get("scope") in ["production", "live", "public"]
    requires_approval = is_irreversible and is_external
    return requires_approval

Muster 2: Der stille Fehler

Aktionen, die nicht blockiert werden, aber Nebeneffekte haben, die erst später sichtbar werden. Email-Drafts, die als gesendet markiert werden, ohne wirklich raus zu gehen. API-Calls, die Testdaten in Produktionsdatenbanken schreiben.

Das Gegenmittel: Jede Aktion mit einem Scope-Tag versehen, das explizit deklariert, wohin die Aktion schreibt.

Muster 3: Die Guard-Inflation

Nach zehn Tagen hatte ich so viele Guards, dass einige sich gegenseitig behinderten. Zwei Guards prüften dieselbe Bedingung mit leicht unterschiedlicher Logik. Der eine ließ durch, was der andere blockierte.

Lösung: Guards müssen einen eindeutigen Scope haben. Kein Guard darf eine Bedingung prüfen, die ein anderer Guard bereits abdeckt. Das klingt offensichtlich, aber in der Praxis entsteht Redundanz schnell.

Autonomie schrittweise freigeben (Tag 15 bis 30)

Der dritte Block ist der, der die meisten Menschen nervös macht: Dem System mehr Freiheit geben.

Aber das ist keine Frage des Vertrauens, sondern der Messung. Ich habe nie gefragt: "Kann ich dem Agenten vertrauen?" Ich habe gefragt: "Was ist die maximal mögliche Konsequenz einer falschen Entscheidung in diesem Kontext?"

Wenn die Antwort ist "ein fehlerhafter Draft-Post, den ich vor dem Publish noch sehe", dann ist das keine Situation, die meine Aufmerksamkeit braucht. Wenn die Antwort ist "eine externe API-Call, die Geld kostet oder Daten verändert", dann bleibt die Grenze.

Das Werkzeug dafür ist eine einfache Klassifikation:

autonomy_levels:
  draft_only:
    description: Agent erstellt, Mensch reviewed und publisht
    examples: [posts, emails, reports]
  execute_with_log:
    description: Agent führt aus, Log wird reviewed
    examples: [data_cleanup, cache_invalidation]
  execute_with_approval:
    description: Agent schlägt vor, Mensch bestätigt
    examples: [payments, deletions, external_api_calls]
  never_autonomous:
    description: Immer Mensch
    examples: [production_deploy, account_deletion, legal_documents]

Jede neue Aktion bekommt bei der Einführung ein Level. Das Level kann hochgestuft werden, aber nur nach mindestens 14 Tagen fehlerfreiem Betrieb.

Was aus drei Zeilen 176 Dateien gemacht hat

Kein Big-Bang-Redesign. Nur konsequente Iteration.

Jede Woche ein Review. Jeder Review bringt zwei bis drei neue Erkenntnisse. Manche führen zu neuen Guards, manche verfeinern bestehende, manche zeigen, dass ein Guard überflüssig ist und gelöscht werden kann.

Die 176 Guards heute decken Kategorien ab, an die ich in Woche eins nicht gedacht hätte: Prompt-Injection-Versuche, unerwartete Token-Verbrauchsmuster, Agenten die auf externe Webhooks schreiben statt auf interne Queues, fehlende Idempotenz bei Retry-Logik.

Keiner davon wäre in einem Workshop entstanden. Alle davon sind aus echtem Betrieb destilliert.

Das beschreibe ich ausführlich in "Läuft ohne mich", inklusive der konkreten Guard-Strukturen, der Log-Auswertung und der Entscheidungslogik für Autonomie-Level.

Wichtigste Erkenntnisse

Governance entsteht im Betrieb, nicht im Workshop. Die erste Regel kommt aus dem ersten echten Problem, nicht aus einer hypothetischen Risikoliste.

Drei Zeilen reichen für den Start. Perfekter Guard-Code am Tag 30 ist besser als kein Guard-Code am Tag 1. Iteration schlägt Planung.

Logs sind das wertvollste Asset. Nicht die Guards selbst, sondern was die Guards aufzeichnen. Ohne strukturierte Events keine systematische Verbesserung.

Autonomie ist messbar, nicht vertrauensbasiert. Die Frage ist nicht "vertraue ich dem Agenten", sondern "was ist der maximale Schaden einer falschen Entscheidung in diesem Kontext".

Guard-Inflation ist real. Mehr Guards bedeuten nicht mehr Sicherheit, wenn sie sich überschneiden oder widersprüchlich sind. Regelmäßiges Audit ist Pflicht.

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.