Warum KI-Modelle Systemaufforderungen unterschiedlich durchsetzen (und was das für die Zuverlässigkeit bedeutet)

Ihre Automatisierung bricht auf höchst frustrierende Weise zusammen: Nichts "stürzt ab", aber Ihre KI hört auf, Ihren Regeln zu folgen.

In der einen Woche hält sich das System an die Vorgaben ("immer gültiges JSON zurückgeben", "niemals nach Passwörtern fragen", "keine Fakten erfinden"). In der nächsten Woche fängt ein anderes Modell - oder dasselbe Modell hinter einem anderen Produkt - an, die Regeln zu biegen, zu viel abzulehnen oder "hilfreiche" Extras zu machen, die nachgelagerte Schritte zunichte machen.

Das liegt nicht daran, dass Sie schlecht im Prompten sind. Es ist eine Realität, wie moderne LLM-Produkte aufgebaut sind.

Wichtige Erkenntnis: Eine "Systemaufforderung" ist keine magische Überbrückung. Sie ist ein Kontrollhebel innerhalb eines größeren Stapels: Modellschulung, Sicherheitsrichtlinien, Produktleitplanken, Werkzeugbeschränkungen und Ausgabevalidierung.

In diesem Beitrag wird erläutert, warum sich die Durchsetzung bei den verschiedenen KI-Modellen unterscheidet und was dies für folgende Bereiche bedeutet Zuverlässigkeit in Arbeitsabläufen kleinerer Unternehmen, wie z. B. Support-Triage, Lead-Qualifizierung, Dokumentenverarbeitung und interne Agenten. Sie erhalten ein praktisches Framework, das Sie auch dann anwenden können, wenn Sie sich nicht für Modellinterna interessieren.

Die Absicht (damit Sie wissen, was Sie bekommen werden)

Sie möchten KI-Automatisierungen erstellen, bei denen der gleiche Input führt zu einem vorhersehbar "sicheren" Output. Das bedeutet Verständnis:

• Woher die Befugnis zur Eingabeaufforderung tatsächlich kommt
• Warum es je nach Anbieter/Modell/Produkt unterschiedlich ist
• Welche Fehlermöglichkeiten in der Produktion wichtig sind
• Was ist zu tun, wenn Aufforderungen nicht ausreichen?

Wenn Sie zunächst eine Auffrischung der Grundlagen wünschen, ist dies der passende Artikel: System-Eingabeaufforderung vs. Benutzer-Eingabeaufforderung: Wie sie das AI-Verhalten prägen.

Ein einfaches mentales Modell: 5 Schichten, die "Gehorsam" formen

Wenn jemand sagt: "Modell A respektiert Systemaufforderungen mehr als Modell B", dann beschreibt er damit in der Regel die kombinierte Wirkung von fünf Schichten:

1. Ausbildung und Schulung - Abstimmung (was das Basismodell zu optimieren gelernt hat)
2. Durchsetzung der Sicherheitspolitik (Nicht verhandelbar auf Lieferantenebene)
3. Regeln für Produktverpackungen (Chat-UI vs. API vs. Agent-Framework)
4. Einschränkungen bei den Werkzeugen (Funktionsaufrufe, zulässige Werkzeuge, Abrufgrenzen)
5. Nachbearbeitung und Validierung (Schemata, Filter, Wiederholungen, Human-in-the-Loop)

Verschiedene Anbieter gewichten diese Ebenen unterschiedlich. Selbst innerhalb eines Anbieters können sich die Gewichtungen je nach verwendeter Schnittstelle ändern.

Warum dies für kleine Unternehmen wichtig ist

Wenn Sie eine Automatisierungslösung betreiben, die E-Mails an Kunden versendet, ein CRM-System aktualisiert oder Rechnungen erstellt, ist Ihnen das egal. warum das Modell hat eine Regel ignoriert. Das ist Ihnen wichtig:

• Eine einzige schlechte Ausgabe kann den Kunden schaden
• Ausfälle sind intermittierend (schwer zu reproduzieren)
• Sie zahlen für erneute Versuche, manuelle Bereinigungen oder verlorenes Vertrauen

Das Ziel ist also nicht, "das gehorsamste Modell zu finden". Das Ziel ist "ein System zu entwickeln, das zuverlässig bleibt, wenn sich das Verhalten ändert".

Warum KI-Modelle die Systemaufforderungen unterschiedlich umsetzen (die wahren Gründe)

1) Das Befolgen von Anweisungen ist ein Ausbildungsziel, kein physikalisches Gesetz

Die meisten LLM, die mit Verbrauchern zu tun haben, sind darauf trainiert, hilfreich, sicher und im Großen und Ganzen korrekt zu sein. Das schafft eine eingebaute Spannung:

• Ihre Systemaufforderung könnte lauten: "Antworte nur mit JSON".
• Die Ausbildung des Modells könnte es dazu bringen, eine Erklärung hinzuzufügen, "um hilfreich zu sein".

Einige Modelle sind eher auf wörtliche Rede ausgerichtet. Andere sind eher auf Konversation eingestellt. Keines von beiden ist "falsch", aber sie verhalten sich unter Druck unterschiedlich.

Realitätsprüfung: Wenn Ihre Automatisierung eine strenge Struktur erfordert, können Sie sich nicht auf "bitte" und "immer" verlassen. Sie brauchen Einschränkungen, die das System überprüfen kann (Schema + Validierung), keine Vibes.

2) Die Richtlinien des Anbieters können Ihre Systemaufforderung (stillschweigend) außer Kraft setzen.

Jeder große Anbieter verfügt über eine Sicherheits- und Richtliniendurchsetzung, die über den Benutzerinhalten und oft auch über den Anweisungen Ihrer App steht.

Das bedeutet zwei wichtige Dinge:

• Das Modell kann sich weigern, auch wenn es von Ihrem System aufgefordert wird, dem nachzukommen.
• Das Modell könnte in einer Umgebung die Anforderungen erfüllen, in einer anderen jedoch ablehnen, da die Sicherheitsbedingungen unterschiedlich sind.

Mit anderen Worten: "System-Eingabeaufforderung" ist die höchste Priorität Anweisung Sie steuern und nicht die Anweisung mit der höchsten Priorität im gesamten Stapel.

Quelle: OpenAI API Docs - "Safety best practices"

3) Die "System-Eingabeaufforderung" ist nicht produktübergreifend standardisiert

In der Branche wird eine ähnliche Sprache verwendet (System-/Benutzer-/Entwickler-Meldungen), die jedoch unterschiedlich umgesetzt wird:

• Einige Produkte behandeln Systemanweisungen als eine privilegierte Nachrichtenrolle.
• Einige führen mehrere Anweisungsquellen zusammen (System + Entwickler + versteckter Sicherheitstext).
• Einige Agenten-Frameworks erzeugen pro Tool-Aufruf zusätzliche versteckte Anweisungen.

Sie können also denselben Text kopieren und einfügen und erhalten unterschiedliche Ergebnisse, weil er in einer anderen Form interpretiert wird.

Quelle: OpenAI API Docs - "Prompting"

4) Die Verwendung von Werkzeugen verändert das Spiel (und kann Modelle "gehorsamer" aussehen lassen)

Ein Modell, das Zugang zu Werkzeugen (Suche, Abruf, Funktionsaufruf) hat, kann auf eine Weise zuverlässig gemacht werden, wie es ein reines Textmodell nicht kann.

Beispiel: "Immer gültiges JSON zurückgeben".

• Ohne Werkzeug: Sie bitten das Modell, sich selbst zu kontrollieren.
• Mit Werkzeugen: können Sie Ausgaben durch ein JSON-Schema erzwingen, ungültige Ausgaben zurückweisen und erneut versuchen.

Wenn Menschen ein Modell dafür loben, dass es "die Regeln befolgt", dann loben sie oft das System, das um es herum aufgebaut wurde.

5) Kontextlängen- und Aktualitätseffekte führen zu einer "Prompt-Drift".

Selbst wenn die Eingabeaufforderung vorhanden ist, können lange Gespräche und große Kontextfenster dazu führen, dass das Modell "abdriftet":

• Es kann zu einer Übergewichtung der letzten Gebrauchsanweisung kommen.
• Es kann Muster aus nicht vertrauenswürdigem Text im Kontext aufgreifen
• Es kann fehlende Details halluzinieren, um hilfreich zu bleiben

Deshalb kann das Verhalten der Eingabeaufforderung in einem kurzen Test stabil aussehen, in der Produktion aber nach 20 Nachrichten, 6 Toolaufrufen und einem eingefügten PDF fehlschlagen.

Wie die "unterschiedliche Durchsetzung" in der Produktion aussieht (Fehlerarten)

Dies sind die Fehlermöglichkeiten, die am häufigsten in realen Automationen auftreten.

Fehlermodus 1: Formatverschiebung (die JSON-Regel bricht)

Was Sie sehen: gibt das Modell Markdown-Zäune zurück, fügt Kommentare hinzu oder gibt JSON-ähnlichen Text aus, der nicht geparst werden kann.

Warum das so ist: das Modell versucht, hilfreich zu sein, oder es hat "gelernt", dass Erklärungen bevorzugt werden.

Wie man damit umgeht:

• Definieren Sie ein explizites Schema für Ausgaben (Felder, Typen, Einschränkungen)
• Validieren Sie die Ausgabe und versuchen Sie es erneut mit einer Aufforderung zur Korrektur
• Fail closed: wenn Validierung zweimal fehlschlägt, Weiterleitung an menschliche Überprüfung

Profi-Tipp: Wenn Ihre Automatisierung von der Struktur abhängt, behandeln Sie "prompt-only JSON" als Prototyp. Die Produktion benötigt eine Schema-Validierung.

Fehlermodus 2: Nicht übereinstimmende Politik (Ablehnungen und Überablehnungen)

Was Sie sehen: ein Modell antwortet normal, ein anderes lehnt ab, ein drittes lehnt nur bei einigen Formulierungen ab.

Warum das so ist: Die Anbieter stimmen die Ablehnungen unterschiedlich ab, und die Produktsicherheitsebenen können je nach Schnittstelle variieren.

Wie man damit umgeht:

• Den Workflow so gestalten, dass eine Ablehnung als normaler Ausgabepfad akzeptiert wird
• Geben Sie Anweisungen für eine "sichere Alternative" ("Wenn Sie ablehnen müssen, schlagen Sie stattdessen X vor")
• Entscheiden Sie im Voraus, welche Aufgaben "erfüllt" und welche "abgelehnt" werden müssen.

Fehlermodus 3: Aufforderungsinjektion (nicht vertrauenswürdiger Text wird zur Anweisung)

Was Sie sehen: das Modell folgt den Anweisungen, die in einer E-Mail, einer PDF-Datei, einer Website oder einer Kundennachricht eingebettet sind ("Vorherige Anweisungen ignorieren...").

Warum das so ist: das Modell kann nicht von sich aus wissen, welcher Text "vertrauenswürdige Richtlinie" und welcher "nicht vertrauenswürdige Daten" ist. Einige Stapel isolieren Inhalte besser als andere.

Wie man damit umgeht:

• Nicht vertrauenswürdigen Text klar abgrenzen und als Daten kennzeichnen
• Verwenden Sie Erlaubnislisten für Aktionen (was kann per E-Mail verschickt werden, was kann in CRM geschrieben werden)
• Hinzufügen eines Schrittes zur Überprüfung der Richtlinien ("Entspricht die Ausgabe den Regeln X, Y, Z?")

Quelle: OWASP Top 10 für LLM-Anwendungen - Prompt Injection (LLM01)

Fehlermodus 4: Versteckte Befehlskollisionen (Ihre Regeln vs. die Regeln des Produkts)

Was Sie sehen: das Modell ignoriert Ihren Ton/Format oder fügt Haftungsausschlüsse hinzu, die Sie nicht gewünscht haben.

Warum das so ist: Chat-Produkte und Vermittlungsrahmen enthalten oft versteckte "Hausstil"- oder Sicherheitsanweisungen, die mit den Ihren konkurrieren.

Wie man damit umgeht:

• Testen Sie in der gleichen Umgebung, in der Sie auch implementieren werden (API vs. UI ist wichtig)
• Halten Sie die Systemaufforderungen kurz und unmissverständlich
• Verlagerung der Komplexität von der System-Eingabeaufforderung zu codegestützten Prüfungen

Fehlermodus 5: Leckage an den Werkzeuggrenzen (das Modell "macht zu viel")

Was Sie sehen: das Modell ruft Werkzeuge auf unerwartete Weise auf oder trifft Annahmen, um eine Aufgabe zu erfüllen.

Warum das so ist: Modelle, die Werkzeuge verwenden, sind darauf optimiert, Aufgaben durchgängig zu lösen. Wenn die Werkzeuggrenze nicht eingeschränkt ist, werden sie "helfen".

Wie man damit umgeht:

• Beschränkung des Werkzeugzugriffs (nur erforderliche Werkzeuge zulassen)
• Rechtfertigungsfelder für risikoreiche Aktionen erforderlich machen
• Hinzufügen eines "Bestätigungs-Gates" vor externen Nebeneffekten (E-Mail senden, CRM aktualisieren)

Ein Entscheidungsrahmen: Wie streng muss Ihre "Systemaufforderung" sein?

Für kleine Unternehmen lautet die richtige Frage nicht: "Welches Modell ist das beste?" Sie lautet:

Wie hoch sind die Kosten für eine einzige fehlerhafte Ausgabe in diesem Arbeitsablauf?

Verwenden Sie diesen einfachen Rahmen:

Schritt 1: Klassifizierung des Arbeitsablaufs nach dem Strahlenradius

• Geringer Explosionsradius: interne Entwürfe, Zusammenfassungen zur Überprüfung durch einen Menschen
• Mittlerer Explosionsradius: CRM-Aktualisierungen, Kennzeichnung, interne Weiterleitung
• Hoher Explosionsradius: kundenorientierte Nachrichten, finanzielle Maßnahmen, Compliance-bezogene Ausgaben

Schritt 2: Anpassung der Leitplanken an das Risiko

Schnell gewinnen: Wenn Ihr Arbeitsablauf mit Kunden oder Geld zu tun hat, sollten Sie nicht über Eingabeaufforderungen diskutieren. Fügen Sie eine Validierungs- und Wiederholungsschleife sowie einen menschlichen Genehmigungsschritt für Grenzfälle hinzu.

Schritt 3: Entscheiden Sie, was "Zuverlässigkeit" in messbaren Begriffen bedeutet

Wählen Sie 2-3 Metriken, die Sie verfolgen können:

• Gültige Ausgaberate (z. B. JSON parst und übergibt Schema)
• Korrektheit der Ablehnung (verweigern, wenn es sein sollte, nachgeben, wenn es sein sollte)
• Aktion Sicherheit (keine unzulässigen Aktionen ausgelöst)
• Abweichung bei Wiederholungsversuchen (wie oft Sie einen zweiten Versuch benötigen)

Hier ist ein kleines Test-Harness wertvoller als eine weitere prompte Neuformulierung.

Praktische Muster, die dafür sorgen, dass Systemaufforderungen zuverlässig "funktionieren"

Diese Muster sind modellunabhängig. Mit ihnen hört man auf, sich auf Gehorsam zu verlassen und beginnt, sich auf Technik zu verlassen.

Muster 1: Halten Sie die Systemaufforderung kurz, spezifisch und testbar

Gute Systemaufforderungen lesen sich wie Richtlinien:

• "Gibt nur JSON zurück, das diesem Schema entspricht."
• "Wenn Ihnen die erforderlichen Daten fehlen, senden Sie needs_human: true."
• "Niemals Passwörter anfordern oder speichern. Wenn Sie gefragt werden, lehnen Sie ab und bieten Sie sichere Alternativen an.

Vermeiden Sie große Blockaden im Rollenspiel. Vermeiden Sie Zielkonflikte ("kreativ sein" + "streng strukturiert sein"). Wenn eine Regel wichtig ist, machen Sie sie testbar.

Muster 2: Anweisungen von Daten trennen (insbesondere bei nicht vertrauenswürdigen Eingaben)

Wenn Sie einen E-Mail-Thread, eine Webseite oder eine PDF-Datei in denselben Kanal wie Anweisungen einfügen, erhöhen Sie das Risiko einer Injektion.

Sicherere Struktur:

• System: Regeln + Ausgabeschema
• Entwickler: Aufgabenvorlage
• Benutzer: eine strukturierte Anfrage (Felder)
• Daten: zitierter/unvertrauter Text mit klaren Trennzeichen

Wenn Ihr Werkzeug nicht über mehrere Kanäle verfügt, können Sie dies mit eindeutigen Beschriftungen und Anschlägen nachbilden.

Muster 3: Fail geschlossen mit Validatoren, nicht offen mit Best-Effort-Ausgabe

Wenn JSON erforderlich ist, validieren Sie es. Wenn die Einhaltung von Richtlinien wichtig ist, überprüfen Sie sie.

Typische Schleife:

1. Ausgabe generieren
2. Validierung der Ausgabe (Schema + Geschäftsregeln)
3. Wenn ungültig: Wiederholungsversuch mit Korrekturaufforderung unter Hinweis auf den Fehler
4. Wenn wieder ungültig: Weiterleitung an die menschliche Überprüfung

Dadurch werden intermittierende Fehler zu verwalteten Ausnahmen und nicht zu stiller Korruption.

Muster 4: Aktionen mit Zulassen-Listen einschränken

Lassen Sie das Modell nicht über beliebige Aktionen entscheiden. Geben Sie ihm ein Menü:

• Erlaubte Kategorien/Tags
• Erlaubte E-Mail-Vorlagen
• Erlaubte CRM-Felder zur Aktualisierung
• Erlaubte Tools zum Aufruf

Das Modell kann innerhalb der Erlaubnisliste wählen, aber es kann nicht erfinden.

Muster 5: Erstellen Sie eine kleine Regressionssuite (und wiederholen Sie sie monatlich)

Nehmen Sie 10-20 echte (bereinigte) Beispiele aus Ihrem Arbeitsablauf. Bewerten Sie Ihre Metriken mit bestanden/nicht bestanden. Speichern Sie den Testsatz.

Wenn Sie eine dieser Angaben ändern, führen Sie die Suite erneut aus:

• Modell/Version
• zeitnahe Formulierung
• Werkzeuge
• Sicherheitseinstellungen
• Ausgabeschema

Wenn Sie bereits eine Prompt-Test-Suite haben, passt dieser Beitrag gut dazu: Wie ChatGPT, Claude und Gemini System- und Benutzereingaben interpretieren (dieselben Tests).

Beispiel: Eine Agentur mit 10 Mitarbeitern führt die Lead-Qualifizierung mit KI durch. Ihre Regressionssuite umfasst 15 Leads: Spam, echte Leads, Randfälle und einen Injektionsversuch. Jede Modellaktualisierung, die die Zahl der "ungültigen JSON" über 2/15 erhöht, löst einen Rollback oder eine Anpassung der Eingabeaufforderung/des Validators aus.

Muster 6: Design für "sichere Degradierung"

Die beste Zuverlässigkeitsstrategie besteht darin, den Ausfallmodus sicher zu machen:

• Wenn unsicher: als unsicher kennzeichnen und an eine Person weiterleiten
• Bei Ablehnung: Bereitstellung eines sicheren Alternativwegs
• Bei fehlenden Daten: Fordern Sie die mindestens erforderlichen Felder an und hören Sie dann auf.

Auf diese Weise verhindern Sie, dass "eine seltsame Ausgabe" zu einem Kundenvorfall wird.

Wohin Sie Ihre Anstrengungen lenken sollen (damit Sie keine Wochen vergeuden)

Wenn Sie ein kleines Unternehmen sind, wollen Sie kein monatelanges Projekt, bei dem Sie Ihre Texte umschreiben müssen. Sie wollen die 80/20.

Setzen Sie Ihre Zeit zuerst hier ein:

• Output-Verträge: Schemata + Validierer
• Aktionsgrenzen: Zulassungslisten + Bestätigungs-Tore
• Test-Kabelbaum: kleine Regressionssuite

Dann verbessern Sie die Eingabeaufforderungen:

• Zweideutigkeit verringern
• Konflikte beseitigen
• Regeln messbar machen

Realitätsprüfung: Teams verbringen oft 80 % ihrer Zeit mit dem Versuch, die Systemaufforderung zu perfektionieren", obwohl 80 % der Zuverlässigkeit von den Validierern und der Gestaltung der Arbeitsabläufe abhängen.

CTA in der Mitte des Beitrags (optional, aber nützlich)

Wenn Sie einen KI-Workflow entwickeln, der sich auf Kunden oder Einnahmen auswirkt, erspart eine schnelle Zuverlässigkeitsüberprüfung eine Menge Nacharbeit. Buchen Sie ein kostenloses Automatisierungsaudit und wir werden die richtigen Leitplanken für Ihr Workflow-Risiko festlegen.

Fazit: Systemaufforderungen sind notwendig, aber nicht ausreichend

KI-Modelle setzen Systemaufforderungen auf andere Weise durch, da die "Befolgung von Systemaufforderungen" das Ergebnis eines ganzen Stapels ist: Training, Richtlinien, Produktumhüllungen, Werkzeugbeschränkungen und Validierung.

Für eine zuverlässige Automatisierung sollten Sie nicht alles auf die Eingabeaufforderung setzen. Verwenden Sie Prompts, um ausdrückliche Absicht und verwenden Sie dann die Technik, um Ergebnisse durchsetzen:

• Struktur validieren (Schemata)
• Aktionen einschränken (Zulassen-Listen)
• Isolierung nicht vertrauenswürdiger Eingaben (Anti-Injection-Muster)
• Messung der Zuverlässigkeit (ein kleiner Test-Kabelbaum)

Wenn Sie Hilfe benötigen, um dies in einen wiederholbaren Prozess zu verwandeln (Prompt-Bibliothek + Test-Suite + Leitplanken), Buchen Sie eine Demo mit Evalics.

FAQs

Warum gehen die verschiedenen KI-Modelle unterschiedlich mit Systemaufforderungen um?

Denn die "Systemaufforderung" wird als eine Mischung aus Schulungen, Produktregeln und Laufzeitsicherheitsebenen implementiert. Die verschiedenen Anbieter setzen unterschiedliche Prioritäten bei Hilfsbereitschaft, Richtlinien und Werkzeugbeschränkungen, so dass die Durchsetzung variiert.

Haben Systemaufforderungen garantiert Vorrang vor Benutzeraufforderungen?

Nein. Systemaufforderungen sind der Anweisungskanal mit der höchsten Priorität, den Sie kontrollieren, aber sie konkurrieren immer noch mit Sicherheitsrichtlinien, Modellanreizen und zweideutigen oder widersprüchlichen Formulierungen. Entwerfen Sie mit Validierung und Fallbacks.

Was ist der häufigste Grund dafür, dass ein Systemprompt in der Produktion ausfällt?

Nicht vertrauenswürdige Eingaben, die in den Anweisungsraum gemischt werden (Prompt Injection), sowie fehlende Validierung der Ausgaben. Behandeln Sie externen Text als Daten, nicht als Anweisungen, und überprüfen Sie Ausgaben, bevor Sie sie ausführen.

Wie kann ich Systemaufforderungen für die Geschäftsautomatisierung zuverlässiger machen?

Halten Sie die Systemaufforderung kurz und testbar, schränken Sie die Ausgaben mit einem Schema ein, validieren Sie und versuchen Sie es erneut, isolieren Sie nicht vertrauenswürdige Inhalte und verwenden Sie eine kleine automatisierte Testsuite, um Abweichungen nach Aktualisierungen zu erkennen.

Sollten sich kleine Unternehmen auf ein einziges Modell für die Zuverlässigkeit festlegen?

Häufig ja. Durch die Standardisierung wird der Wartungsaufwand reduziert und das Verhalten kann leichter getestet werden. Wenn Sie mehrere Modelle verwenden, tun Sie dies absichtlich: eines für strenge Arbeitsabläufe und ein anderes für kreative Entwürfe.

Wie oft sollte ich die Prompts nach einem Modell- oder Anbieterwechsel erneut testen?

Führen Sie bei jeder Änderung von Modell/Version, Eingabeaufforderungen, Werkzeugen oder Sicherheitseinstellungen einen neuen Test durch. Planen Sie außerdem regelmäßige Regressionstests ein, da die Anbieter das Verhalten im Laufe der Zeit aktualisieren - auch wenn sich Ihr Code nicht ändert.

Über den Autor

Kevin Michael Schindler ist KI-Automatisierungsexperte bei Evalics. Er hilft kleinen Unternehmen und Teams bei der Implementierung praktischer Automatisierungssysteme, die Zeit sparen und den Betriebsaufwand verringern.