Ein KI-System braucht ein ausführbares Regelwerk

Viele KI-Projekte beginnen mit einem langen Prompt. Er beschreibt Rolle, Ton, Ziel, Ausnahmen und manchmal sogar die gewünschte Arbeitsweise. Solange das System nur Text entwirft, kann das erstaunlich gut funktionieren. Sobald es Dateien verändert, Werkzeuge verwendet oder mehrere Schritte selbstständig verbindet, reicht sprachliche Absicht nicht mehr aus. Das System braucht ein Regelwerk, das Arbeit nicht nur erklärt, sondern begrenzt und prüfbar macht.

Flüssige Sprache ist noch keine Governance

Ein Sprachmodell kann Regeln überzeugend wiederholen und sie dennoch im falschen Moment übergehen. Das geschieht nicht zwingend aus Ungehorsam. Häufig sind Anweisungen zu allgemein, widersprüchlich oder nicht mit der konkreten Handlung verbunden. „Arbeite sicher" sagt nicht, ob ein Agent eine Abhängigkeit installieren darf. „Frage vor kritischen Schritten" definiert weder kritisch noch die Form der Freigabe.

Governance beginnt daher mit operationalisierbaren Unterschieden. Lesen ist etwas anderes als Schreiben. Eine Vorschau ist etwas anderes als Versand. Ein lokaler Test ist etwas anderes als Deployment. Eine reversible Dateiänderung ist etwas anderes als das Löschen von Daten. Solche Zustände müssen im Regelwerk benannt werden.

Regeln brauchen eine erkennbare Hierarchie

Ein System arbeitet zuverlässiger, wenn klar ist, welche Dokumente wofür gelten. Dauerhafte Projektregeln gehören in kurze, gut auffindbare Instruktionsdateien. Änderliche Ziele, Scope und Datenzone gehören in einen Projektbrief. Akzeptanzkriterien beschreiben, woran ein Ergebnis als fertig erkannt wird. Entscheidungen halten fest, welche Alternative verbindlich gewählt wurde. Ein Handoff dokumentiert den aktuellen Zustand.

Diese Trennung verhindert, dass eine veraltete Projektidee in einer immer geladenen Regeldatei weiterlebt. Sie verhindert auch, dass ein einzelnes Ticket unbemerkt eine dauerhafte Sicherheitsgrenze überschreibt. Ein Regelwerk ist nicht ein großes Dokument, sondern eine geordnete Beziehung zwischen verschiedenen Dokumenttypen.

Eine Regel muss an eine Handlung gebunden sein

„Keine externen Aktionen ohne Freigabe" wird erst ausführbar, wenn das System externe Aktionen erkennen kann. Dazu zählen etwa Versand, Veröffentlichung, Deployment, Kosten, Löschung, Zugriffserweiterung oder die Nutzung produktiver Zugangsdaten. Vor der Wirkung muss ein Vorschauzustand entstehen.

Eine gute Vorschau nennt Ziel, Aktion, Payload, erwartete Folge und Rückrollmöglichkeit. Die freigebende Person sieht damit nicht nur, dass etwas passieren soll, sondern was genau. Die Entscheidung kann lauten: einmal erlauben, ablehnen oder überarbeiten. Eine pauschale Zustimmung für alle zukünftigen Fälle wäre eine eigene Policy-Änderung.

Skills sind ausführbares Wissen

Ein Skill ist mehr als ein wiederverwendbarer Prompt. Er verbindet Auslöser, Eingaben, erlaubte Werkzeuge, Arbeitsschritte, Outputvertrag und Stoppsignale. Dadurch wird Wissen handlungsfähig. Genau deshalb braucht ein Skill dieselbe Sorgfalt wie Code.

Er sollte eine begrenzte Fähigkeit besitzen, nicht eine diffuse Mission. „Erstelle eine quellengebundene Zusammenfassung aus drei benannten Dokumenten" ist prüfbarer als „Sei mein Wissensagent". Ein enger Skill lässt sich mit positiven, negativen und reparierbaren Fällen testen. Ein zu breiter Skill kann zwar beeindruckend wirken, aber seine Fehler lassen sich kaum lokalisieren.