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.

Beispiele und Gegenbeispiele geben Regeln Kontur

Abstrakte Regeln werden erst an Fällen eindeutig. Zu „nicht veröffentlichen ohne Freigabe" gehört ein positiver Fall: Der Agent erstellt eine Vorschau und wartet. Ein negativer Fall zeigt, dass er eine veröffentlichungsfertige Datei nicht automatisch live stellt. Ein reparierbarer Fall zeigt, wie er reagiert, wenn Ziel oder Empfänger unklar ist.

Gegenbeispiele sind besonders wichtig, weil sie oberflächlich ähnlich aussehen können. Eine lokale Vorschau darf erlaubt sein, während derselbe Inhalt im öffentlichen CMS eine Freigabe braucht. Eine Datei darf in einem Arbeitsverzeichnis ersetzt werden, während eine produktive Datenbank nicht verändert werden darf. Regeln gewinnen ihre Wirkung an der Grenze zwischen ähnlichen Fällen.

Versionierung macht Regeln verantwortbar

Regeln verändern Verhalten. Deshalb müssen Änderungen an Regeln wie Änderungen an Code behandelt werden. Es sollte sichtbar sein, warum eine Regel geändert wurde, welcher Vorfall oder Testfall sie motiviert hat, welche Systeme sie erben und wie sie zurückgenommen werden kann.

Nach einer Regeländerung reicht es nicht zu prüfen, ob der gewünschte neue Fall funktioniert. Auch bestehende positive und negative Fälle müssen erneut laufen. Eine neue Sicherheitsregel kann sonst jede harmlose Arbeit unnötig blockieren. Umgekehrt kann eine bequemere Formulierung unbeabsichtigt eine frühere Grenze aufweichen.

Ein Regelwerk braucht Tests

Die Qualität eines Regelwerks zeigt sich nicht daran, wie vollständig es klingt, sondern wie es sich in wiederholbaren Situationen verhält. Mindestens drei Arten von Fällen sind nötig: Der positive Fall prüft erlaubte Arbeit. Der negative Fall prüft, ob eine verbotene Wirkung gestoppt wird. Der reparierbare Fall prüft, ob das System fehlende Quellen, unklaren Scope oder einen Testfehler erkennt und den richtigen nächsten Schritt nennt.

Messbar werden unter anderem Akzeptanzquote, Evidenzvollständigkeit, Grenzverletzungen, unnötige Eskalationen und Handoff-Qualität. Kein einzelner Wert genügt. Ein System, das schneller arbeitet, indem es Freigaben umgeht, ist nicht effizienter, sondern schlechter kontrolliert.

Das ausführbare Regelwerk

# MISSION
Welches begrenzte Ergebnis soll entstehen?

# QUELLEN UND WAHRHEIT
Welche Dokumente sind verbindlich, welche nur ergänzend?

# ERLAUBTE WERKZEUGE
Welche Fähigkeit ist für diesen Zustand nötig?

# GRENZEN
Was darf vorbereitet, aber nicht ausgelöst werden?

# STOPPSIGNALE
Wann muss das System fragen, übergeben oder abbrechen?

# VERIFIKATION
Welche Tests und Akzeptanzkriterien belegen das Ergebnis?

# HANDOFF
Welche Änderung, Evidenz, Annahme und Restunsicherheit bleibt?

Ein gutes Regelwerk macht ein System nicht klein. Es macht seine Leistungsfähigkeit adressierbar. Es zeigt, welche Handlung unter welchen Bedingungen erlaubt ist. Damit wird aus einer wohlklingenden Assistenz ein Arbeitsprozess, der geprüft, verbessert und verantwortet werden kann.

Alle Materialien zum Download – die Themenübersicht und das Übungsblatt: