Instruktions-Hierarchie und Regel-Konflikte

Prompts wachsen zu Regelwerken

Ein System-Prompt beginnt als Absatz und endet als Regelwerk. Jeder Vorfall fügt eine Zeile hinzu, jede Fachabteilung eine Ausnahme, jedes Audit eine Formulierung. Nach einem Jahr stehen dort vierzig Regeln, die niemand mehr gleichzeitig im Kopf hat — und deren Zusammenspiel nie jemand geprüft hat, weil jede einzelne für sich plausibel ist.

Das erzeugt eine eigene Fehlerklasse. Nicht „das Modell hält sich nicht an die Regel“, sondern: Zwei Regeln verlangen Verschiedenes, und nichts sagt, welche gewinnt. Das Modell entscheidet dann pro Aufruf — nicht willkürlich, aber auch nicht nach einer Regel, die irgendwo aufgeschrieben ist. Von außen sieht das wie Unzuverlässigkeit aus und ist eine Lücke in der Spezifikation.

Diese Fehlerklasse wird zuverlässig falsch diagnostiziert, und zwar aus einem nachvollziehbaren Grund: Sie sieht wie mangelnde Regeltreue aus. Ein Ticket meldet, das Modell halte sich nicht an die Längenvorgabe, jemand betont die Vorgabe stärker, das Verhalten bleibt uneinheitlich — und niemand kommt auf die Idee, dass eine andere Regel im selben Prompt genau das Gegenteil verlangt. Die Prüffrage dagegen ist billig: Gibt es für den beobachteten Fall eine zweite Regel, die zutrifft? Wenn ja, ist Betonung die falsche Behandlung.

Ebenen mit unterschiedlicher Autorität

Der erste Ordnungsschritt ist keine Erfindung der Praxis, sondern ein Trainingsziel. Wallace und Kollegen haben 2024 die Instruktions-Hierarchie beschrieben und als Kernschwachstelle benannt, dass Modelle System-Prompts genauso behandelten wie nicht vertrauenswürdige Nutzereingaben. Ihr Vorschlag ordnet Anweisungen nach Privilegien: hoch für System-Prompts der Anwendungsentwickler, niedrig für Text von nicht vertrauenswürdigen Nutzern und Dritten.

Instruktions-Hierarchie — Eine Rangordnung der Anweisungsquellen nach Privileg. Bei Konflikt gewinnt die höhere Ebene, und die niedrigere wird selektiv ignoriert. Der Rang folgt der Herkunft der Anweisung, nicht ihrer Formulierung oder ihrer Position im Text.

Das Ergebnis der Arbeit ist bemerkenswert: Auf ein Modell angewandt erhöhte die trainierte Hierarchie die Robustheit deutlich — auch gegen Angriffsarten, die im Training nicht vorkamen, und ohne die üblichen Fähigkeiten zu beschädigen. Für dich als Autor heißt das: Die Ebenen sind wirksam. Aber sie sind es, weil sie trainiert wurden, nicht weil du sie im Text behauptest.

Ebene

Herkunft und Privileg

System-Prompt

Vom Betreiber der Anwendung. Höchstes Privileg.

Nutzer-Turn

Von der Person am Gerät. Mittleres Privileg — legitime Wünsche, keine Betreiberrechte.

Inhalt aus Werkzeugen und Dokumenten

Von Dritten, oft unbekannt. Niedrigstes Privileg — Daten, keine Anweisungen.

Die Hierarchie ist trainiert, nicht erzwungen

Jetzt der Teil, den man aussprechen muss, damit die Hierarchie nicht als Sicherheitsgrenze missverstanden wird. Eine Ebene, die im Modellverhalten liegt, ist eine starke Neigung — keine durchgesetzte Grenze. Es gibt keinen Compiler, der eine niedrigprivilegierte Anweisung ablehnt, und keine Ausnahme, die geworfen wird.

Praktisch bedeutet das eine Zweiteilung, die den Rest des Moduls trägt: Für gutartige Konflikte — zwei Fachregeln, die sich widersprechen, ein Nutzer, der etwas anderes will als der Betreiber vorgesehen hat — ist die Hierarchie das richtige und ausreichende Werkzeug. Für bösartige Fälle, in denen jemand die Ebenen absichtlich unterlaufen will, ist sie eine Hürde und keine Mauer; dort brauchst du begrenzte Handlungsmacht und Freigaben, und das ist Thema des Moduls Injection-Abwehr im Systemdesign.

Der Operator-Kanal: wo Betreiber-Anweisungen hingehören

Aus der Hierarchie folgt eine sehr konkrete Bauregel, die in der Praxis oft verletzt wird: Eine Anweisung des Betreibers gehört in die Ebene mit Betreiber-Privileg — also in die System-Rolle. Nicht an den Nutzer-Turn angehängt, nicht als Vorspann in den Text der Nutzerfrage gesetzt, nicht als Nachsatz hinter das Dokument geklebt.

Der Fehler entsteht meist aus Bequemlichkeit oder aus Cache-Gründen: Der System-Prompt ist gesetzt und stabil, und eine neue Regel soll mitten im Gespräch dazukommen. Sie landet dann als Text im Nutzer-Turn — und verliert damit genau die Autorität, wegen der sie geschrieben wurde. Zusätzlich sitzt sie jetzt in der Nachbarschaft von Nutzereingaben, ist also leichter zu überschreiben.

Für diesen Fall gibt es die richtige Bauform: eine Nachricht mit der Rolle system mitten in der Nachrichtenliste. Anthropic beschreibt sie ausdrücklich als den Kanal für Betreiber-Anweisungen, die mitten im Gespräch dazukommen — sie behält Betreiber-Privileg, und sie erhält den zwischengespeicherten Präfix, weil das Feld system oben unangetastet bleibt. Verfügbarkeit und Platzierungsregeln hängen vom Modell ab und sind vor dem Einsatz nachzulesen.

Steht dieser Kanal nicht zur Verfügung, gibt es zwei ehrliche Auswege und einen schlechten. Ehrlich ist erstens, die Regel in den oberen System-Prompt zu ziehen und den Cache-Verlust zu akzeptieren — teuer, aber mit der richtigen Autorität. Ehrlich ist zweitens, den Fall gar nicht per Prompt zu lösen, sondern die Anwendung anders zu verzweigen, etwa in einen zweiten Prompt für den anderen Modus. Schlecht ist, die Regel als Text neben die Nutzereingabe zu setzen und sich auf die Formulierung zu verlassen: Damit hängt Betreiber-Verhalten an einer Ebene, auf der der Nutzer schreiben darf.

Konflikte innerhalb einer Ebene deklarieren

Die Hierarchie löst Konflikte zwischen Ebenen. Der häufigste Konflikt im Alltag liegt aber innerhalb einer Ebene: zwei Regeln, beide im System-Prompt, beide vom Betreiber, beide gültig — und unvereinbar in einem bestimmten Fall. Dort hilft kein Privileg, weil beide dasselbe haben.

Ein Beispiel, das in fast jedem Support-System steckt: Antworte in höchstens 3 Sätzen. und Nenne bei rechtlichen Themen immer den vollständigen Haftungshinweis. Der Haftungshinweis ist vier Sätze lang. Beide Regeln sind sinnvoll, keine ist falsch, und in diesem Fall gewinnt die, die das Modell gerade stärker gewichtet.

• Präzedenz benennen — welche Regel bricht welche, ausdrücklich im Text: die Haftungspflicht schlägt die Längengrenze.
• Bedingung präzisieren — statt zweier globaler Regeln eine mit Anwendungsbereich: höchstens 3 Sätze, außer bei rechtlichen Themen.
• Konflikt auflösen — den Widerspruch beseitigen, indem eine Regel umformuliert wird: höchstens 3 Sätze zusätzlich zum Pflichthinweis.
• Nicht: beides stehen lassen und hoffen — das ist der Zustand, aus dem der Vorfall kommt.

Konditionale Regeln: wo Konflikte sich verstecken

Regeln mit Bedingung — „bei Geschäftskunden …“, „außerhalb der Geschäftszeiten …“, „wenn der Vorgang eskaliert ist …“ — sind der beste Ort, um Konflikte zu verbergen. Solange die Bedingungen sich nicht überschneiden, ist alles in Ordnung. Sobald zwei zutreffen, ist wieder offen, welche gilt.

Muster

Was schiefgeht

Überlappende Bedingungen

Geschäftskunde und eskaliert — beide Regeln greifen, keine hat Vorrang.

Unvollständige Fallabdeckung

Kein Fall trifft zu, und für den Rest ist nichts festgelegt.

Implizite Bedingung

Die Regel gilt „normalerweise“ — ein Anwendungsbereich, den niemand prüfen kann.

Bedingung auf Information, die fehlt

Die Regel verlangt den Kundentyp, und der steht nicht im Kontext.

Die letzte Zeile ist die unangenehmste, weil sie wie ein Regelproblem aussieht und ein Kontextproblem ist. Eine Bedingung, deren Eingangsgröße gar nicht im Prompt steht, wird geraten — und dann greift die Regel manchmal und manchmal nicht, ohne erkennbares Muster.

Regel-Wildwuchs kostet real

Regeln kosten dreifach, und nur die erste Kosten sieht man in der Rechnung. Erstens Tokens, bei jedem Aufruf. Zweitens Wechselwirkungen: Bei 40 Regeln gibt es 780 Paare, die einander widersprechen könnten — niemand prüft 780 Paare, also prüft niemand. Drittens Verdünnung: Die wichtige Regel steht zwischen 39 anderen und konkurriert mit ihnen.

Daraus folgt eine Haltung, die dem Reflex widerspricht: Nach einem Vorfall ist die erste Frage nicht „welche Regel fügen wir hinzu?“, sondern „welche vorhandene Regel hat hier nicht getragen und warum?“. Sehr oft ist die Antwort, dass eine bestehende Regel zu unspezifisch war — und dann ist das Ergebnis eine geänderte, nicht eine zusätzliche Regel.

Die Zahl 780 ist keine Rhetorik, sondern die Anzahl der Paare bei 40 Elementen. Sie erklärt, warum Wildwuchs eine Schwelle hat statt einer Steigung: Bei 8 Regeln sind es 28 Paare, die ein Mensch im Kopf überschlagen kann; bei 20 Regeln sind es 190, und die Prüfung ist praktisch aufgegeben. Der Zeitpunkt, zu dem ein Regelwerk unprüfbar wird, liegt also viel früher als der, zu dem es unübersichtlich aussieht — und deshalb bemerkt es niemand.

Ein Regelwerk, das man prüfen kann

Konflikte testen statt hoffen

Ein aufgelöster Konflikt bleibt nur aufgelöst, wenn er getestet ist. Der Testfall dafür hat eine besondere Form: Er ist eine Eingabe, in der beide Bedingungen zutreffen, mit der Auflösung als Erwartung. Ein solcher Fall gehört zu jeder Präzedenz-Entscheidung — sonst hebt die nächste Prompt-Änderung sie unbemerkt auf.

Das ist der Punkt, an dem Regelwerk und Eval-Set zusammenkommen. Ein Prompt mit vierzig Regeln und ohne Konflikt-Testfälle ist nicht wartbar: Jede Änderung kann jede Präzedenz kippen, und niemand erfährt es. Wie so eine Fallmenge zusammengestellt und als Gate genutzt wird, behandelt das Modul Eval-Sets und Regressionstests.

Der Testfall hat noch einen zweiten Nutzen, der beim Schreiben auffällt: Er zwingt dich, den Konflikt an einem konkreten Fall zu formulieren. Erstaunlich oft stellt sich dabei heraus, dass der vermutete Konflikt in der Praxis nie auftritt — die beiden Bedingungen schließen sich fachlich aus, und die Präzedenz muss gar nicht entschieden werden. Genauso oft zeigt sich das Gegenteil: Der Fall ist häufig, und die Auflösung, die im Meeting einleuchtend klang, ist am Beispiel offensichtlich falsch.

Wer darf welche Ebene ändern

Die Ebenen haben unterschiedliche Autorität — dann muss auch unterschiedlich sein, wer sie schreiben darf. Ein System-Prompt trägt Betreiber-Privileg; wenn ihn jeder aus dem Support-Team in einem Textfeld ändern kann, ist die Hierarchie organisatorisch ausgehöhlt, auch wenn sie technisch greift.

Ebene

Wer schreibt, und wie

System-Prompt

Betreiber, über Versionskontrolle und Review — wie Code.

Betreiber-Anweisung im Gespräch

Anwendungslogik, aus geprüften Vorlagen — nicht aus freiem Nutzertext zusammengesetzt.

Nutzer-Turn

Nutzer, unbeschränkt — deshalb darf davon keine Autorität abhängen.

Dokument- und Werkzeuginhalt

Dritte, unkontrolliert — Daten, niemals Anweisung.

Was die Hierarchie nicht leistet

Zum Abschluss die Abgrenzung, damit nichts überdehnt wird: Die Hierarchie ordnet Anweisungen nach Herkunft und löst damit gutartige Konflikte. Sie ist keine Zugriffskontrolle, kein Filter und keine Garantie — und sie hilft nicht bei zwei widersprüchlichen Regeln auf derselben Ebene, weil dort kein Privileg unterscheidet.

Zusammenfassung — gleich im Check

Du kennst jetzt die Ordnung und ihre Grenzen: Ebenen nach Herkunft mit System-Prompt oben und Fremdinhalt unten, die Hierarchie als trainierte Neigung und nicht als Grenze, den Operator-Kanal für Betreiber-Anweisungen mitten im Gespräch, deklarierte Präzedenz für Konflikte innerhalb einer Ebene, disjunkte und vollständige Bedingungen mit im Kontext vorhandenen Eingangsgrößen, die dreifachen Kosten des Wildwuchses und den Konflikt-Testfall als das, was eine Präzedenz haltbar macht.