System Prompts erklärt

Viele Chat-Systeme beginnen mit Anweisungen, die der Nutzer nie zu sehen bekommt. Bevor die erste Nachricht verarbeitet wird, erhält das Modell einen System Prompt, also eine Anweisung, die festlegt, welche Rolle es einnimmt, welche Werkzeuge verfügbar sind, welche Grenzen gelten und wie Antworten aussehen sollen. Dieser unsichtbare Prolog prägt das Verhalten des Systems: ob es förmlich oder locker antwortet, ob es Code ausführen kann, ob es bei bestimmten Themen ablehnt.

Durch versehentliche Offenlegungen, gezielte Extraktion und gelegentliche Veröffentlichungen der Anbieter sind in den letzten Jahren System Prompts großer KI-Produkte öffentlich geworden. Diese Dokumente sind keine stabilen Baupläne der Systeme. Sie sind Momentaufnahmen, teils unvollständig, teils nicht unabhängig verifizierbar und oft an eine bestimmte Produktversion gebunden. Trotzdem sind sie aufschlussreich, weil sie zeigen, mit welchen Anweisungsstrukturen Anbieter Verhalten steuern, Sonderfälle abfangen und bekannte Schwächen einzelner Modelle ausgleichen.

Ein Beispiel dafür lieferte 2026 OpenAIs Codex CLI: In öffentlich gewordenen Systemanweisungen tauchte laut Golem.de mehrfach ein auffällig spezifisches Verbot auf, bestimmte Fantasiewesen und Tiere zu erwähnen, sofern sie nicht eindeutig relevant sind. Solche Sätze wirken nicht wie allgemeine Prompt-Design-Prinzipien, sondern eher wie temporäre Korrekturen gegen ein beobachtetes Modellverhalten. Genau deshalb lassen sich Leaks nur vorsichtig auswerten: Ein Prompt kann grundlegende Architekturentscheidungen sichtbar machen, aber auch bloß eine konkrete Schwachstelle einer Modellversion überdecken.

Dieser Artikel analysiert wiederkehrende Muster und Designprinzipien, ohne die öffentlich gewordenen Prompts als dauerhaft gültige Blaupausen zu behandeln. Interessant ist weniger der genaue Wortlaut als die Frage, welche Arten von Anweisungen immer wieder auftauchen und wo ihre Grenzen liegen.

Für die Grundlagen des Prompt Engineering - Techniken wie Chain-of-Thought, Few-Shot Learning und Prompt Chaining - sei auf die Einführung in Prompt Engineering verwiesen. Welche dieser Techniken einer empirischen Prüfung standhalten, untersucht der Artikel Von der Anekdote zur Evidenz.

Was ist ein System Prompt?

Die drei Rollen der Chat-API

Moderne LLM-APIs strukturieren Konversationen in drei Rollen:

• System: Die initiale Anweisung, die das Verhalten des Modells definiert. Wird vor allen Nutzernachrichten verarbeitet und setzt den Rahmen für die gesamte Konversation.
• User: Die Eingaben des Nutzers.
• Assistant: Die Antworten des Modells.

[System]  "Du bist ein hilfreicher Assistent für Python-Programmierung.
           Antworte auf Deutsch. Gib immer Codebeispiele."
[User]    "Wie sortiere ich eine Liste?"
[Assistant] "In Python gibt es zwei Wege, eine Liste zu sortieren..."

Der System Prompt ist konzeptionell privilegiert, er wird vom Modell als Anweisung des Betreibers behandelt und nicht als einfache Nutzereingabe. In der Praxis bedeutet das: Das Modell gewichtet Anweisungen im System Prompt höher als widersprüchliche Anweisungen im User Prompt. Diese Privilegierung ist jedoch nicht technisch garantiert, sondern ein durch Training und Systemarchitektur gestütztes Verhalten. Dieser Unterschied ist wichtig für den Abschnitt zu Sicherheit.

System Prompt vs. User Prompt vs. Kontext

Die Abgrenzung ist in der Praxis weniger scharf als in der Theorie:

In der Praxis verschwimmen die Grenzen: Viele Anwendungen injizieren dynamischen Kontext, etwa Suchergebnisse, Datenbankabfragen oder Nutzerprofildaten. Der System Prompt wird damit zum Konfigurationskanal, über den die Anwendung das Modellverhalten zur Laufzeit steuert.

Anatomie geleakter System Prompts

System Prompts von ChatGPT, Claude, Copilot und Gemini sind auf verschiedenen Wegen öffentlich geworden, teils durch gezielte Prompt-Injection-Versuche, teils durch Dokumentations-Leaks, teils durch offizielle Veröffentlichungen der Anbieter selbst. Die folgende Analyse basiert auf öffentlich zugänglichen Versionen und fokussiert sich auf strukturelle Muster, nicht auf den Wortlaut. Sie behandelt diese Prompts als Momentaufnahmen, nicht als vollständige Dokumentation der jeweiligen Systeme.

Gemeinsamer Aufbau

Trotz unterschiedlicher Länge und Detailtiefe zeigen viele analysierte System Prompts eine ähnliche Grundstruktur. Sie lassen sich in wiederkehrende Bausteine zerlegen:

1. Identität und Wissenstand

Viele System Prompts beginnen mit einer Selbstbeschreibung: Rolle, Wissensstand, aktuelles Datum und verfügbare Umgebung. Diese Festlegung ist praktisch notwendig, weil das Modell ohne sie keine verlässliche Aussage über sich selbst treffen kann. Es kennt seinen eigenen Namen, seinen Anbieter und sein Trainingsdatum nur dann zuverlässig, wenn diese Informationen zur Laufzeit gesetzt werden.

Typische Elemente sind: - Modellname und Version - Knowledge Cutoff-Datum - Aktuelles Datum (dynamisch injiziert) - Betreiber-Identifikation

2. Fähigkeiten und Grenzen

Der zweite Block definiert, was das Modell kann und was nicht. Hier wird explizit aufgezählt, welche Tools zur Verfügung stehen, ob das Modell Bilder generieren, Code ausführen oder im Web suchen kann. Ebenso wichtig sind die Grenzen dieser Fähigkeiten.

Auffällig ist die Explizitheit: Statt dem Modell zu überlassen, seine Fähigkeiten selbst einzuschätzen, werden sie aufgezählt. Ein Modell, dem gesagt wird "Du kannst keine Bilder sehen", wird Bildanfragen in vielen Fällen ablehnen, selbst wenn die zugrunde liegende Modellfamilie technisch multimodal wäre. Die Produktkonfiguration kann vorhandene Fähigkeiten begrenzen.

3. Verhaltensregeln

Der umfangreichste Block vieler analysierter Prompts betrifft Verhaltensregeln, von allgemeinen Prinzipien bis zu hochspezifischen Einzelfällen.

Die Regeln folgen einem Muster gestufter Spezifität: - Allgemeine Prinzipien: "Sei hilfreich, harmlos und ehrlich" - Domänenspezifische Regeln: "Bei medizinischen Fragen: Verweise auf Fachpersonal" - Einzelfallregeln: "Wenn der Nutzer nach X fragt, antworte mit Y"

Die Granularität der Einzelfallregeln ist oft hoch. Sie kann darauf hindeuten, dass allgemeine Prinzipien für bestimmte Produktanforderungen nicht ausreichen oder dass einzelne Modellschwächen nachträglich abgefangen werden. Das Vorgehen ähnelt dem Few-Shot-Ansatz aus dem Prompt Engineering, ist aber nicht immer als allgemeines Designprinzip zu verstehen.

4. Output-Formatierung

Viele Prompts enthalten Anweisungen zur Formatierung der Ausgabe: Markdown, Antwortlänge, Listen, Fließtext oder LaTeX für Formeln.

Diese Regeln wirken trivial, haben aber erheblichen Einfluss auf die Nutzererfahrung. Ein Modell, das jede Antwort mit einer ausführlichen Einleitung beginnt, fühlt sich langsam an. Eines, das zu knapp antwortet, wirkt wenig hilfreich. Die Formatierungsregeln sind ein Ort, an dem sich auch die "Persönlichkeit" des Systems manifestiert.

5. Sicherheitsanweisungen

Der letzte Block enthält Anweisungen zu Inhalten, die das Modell ablehnen oder einschränken soll. Die Struktur variiert zwischen den Anbietern, aber gemeinsame Elemente sind:

• Kategorische Ablehnungen (z.B. Anleitungen für Waffen, illegale Aktivitäten)
• Kontextsensitive Einschränkungen (z.B. medizinische Ratschläge nur mit Disclaimer)
• Eskalationsmechanismen (z.B. bei Hinweisen auf Selbstgefährdung)
• Meta-Schutz: Anweisungen, den eigenen System Prompt nicht preiszugeben

Unterschiede zwischen den Anbietern

Bei aller strukturellen Ähnlichkeit zeigen sich charakteristische Unterschiede in der Philosophie:

OpenAI (ChatGPT)

OpenAI setzt auf detaillierte Einzelfallregeln. Der System Prompt enthält umfangreiche Listen spezifischer Szenarien mit vorgegebenen Reaktionen. Der Ansatz ist regelbasiert: Für möglichst viele Situationen wird das erwartete Verhalten explizit definiert. Geleakte Versionen des ChatGPT-System-Prompts sind über Sammlungen wie PromptCraft auf GitHub öffentlich einsehbar und zeigen diesen Detailgrad.

Anthropic (Claude)

Anthropic betont Prinzipien stärker als Einzelfallregeln. Statt jede Situation einzeln aufzuzählen, werden übergreifende Werte formuliert, aus denen das Modell Einzelfallentscheidungen ableiten soll. Der Ansatz ist stärker prinzipienbasiert, mit expliziter Aufforderung zum Abwägen. Anthropic veröffentlicht System Prompts offiziell und beschreibt seine Sicherheitsphilosophie unter anderem über Constitutional AI.

Google (Gemini)

In öffentlich kursierenden Gemini-Prompts scheinen Tool-Definitionen und Fähigkeiten stärker in die Systemanweisungen integriert zu sein. Die Grenze zwischen "Was bin ich?" und "Was kann ich?" wirkt dort fließender, was zur engen Integration mit Google-Diensten passen würde. Aus Leaks allein lässt sich daraus aber keine stabile Anbieterphilosophie ableiten.

Diese Unterschiede sind nicht nur technische Details. Sie deuten auf unterschiedliche Philosophien der KI-Sicherheit hin. Der regelbasierte Ansatz ist kontrollierbarer, aber brüchig bei unvorhergesehenen Szenarien. Der prinzipienbasierte Ansatz ist flexibler, aber weniger vorhersagbar. In der Praxis konvergieren die Ansätze: Anbieter nutzen meist eine Mischung aus beiden.

Abgeleitete Designprinzipien

Aus der Analyse lassen sich einige wiederkehrende Muster ableiten, die auch für eigene Anwendungen nützlich sind:

1. Explizite Priorisierung

Die Prompts definieren eine klare Hierarchie: Sicherheitsregeln > Betreiberanweisungen > Nutzerwünsche. Diese Priorisierung ist nicht implizit, sondern wird dem Modell explizit mitgeteilt. Wenn ein Nutzer etwas verlangt, das einer Sicherheitsregel widerspricht, weiß das Modell, welche Anweisung Vorrang hat.

Für eigene System Prompts heißt das: Widersprüchliche Anforderungen brauchen eine explizite Priorisierung.

2. Fallback-Verhalten

Für den Fall, dass das Modell unsicher ist, definieren alle Prompts Fallback-Strategien: "Wenn du dir nicht sicher bist, sage es offen" oder "Im Zweifel lieber ablehnen als falsch antworten". Diese Fallbacks verhindern, dass das Modell bei Grenzfällen halluziniert oder inkonsistent reagiert.

Für eigene System Prompts heißt das: Unklare Fälle brauchen ein definiertes Fallback-Verhalten.

3. Positive statt negative Formulierung

Robuste Regeln beschreiben häufig gewünschtes Verhalten statt nur Verbote. "Antworte sachlich und belege Aussagen" ist meist hilfreicher als "Halluziniere nicht". Negative Anweisungen können in manchen Fällen weniger robust sein, weil das Modell das Konzept aktiviert, das es vermeiden soll.

Für eigene System Prompts heißt das: Gewünschtes Verhalten konkret beschreiben, Verbote aber nicht zur einzigen Steuerungsform machen.

4. Kontextualisierung statt Absolutheit

Statt absoluter Verbote nutzen die Prompts kontextsensitive Regeln: "Bei medizinischen Fragen: Antworte sachlich, aber verweise auf Fachpersonal" statt "Beantworte keine medizinischen Fragen". Dieser Ansatz ist robuster, weil er dem Modell erlaubt, den Kontext zu berücksichtigen, anstatt binäre Entscheidungen zu treffen.

Für eigene System Prompts heißt das: Regeln an Kontexte binden statt pauschal formulieren.

5. Dynamische Injektion

Viele produktive System Prompts sind nicht vollständig statisch. Anbieter injizieren dynamische Informationen: aktuelles Datum, Nutzer-Einstellungen, verfügbare Tools, Gesprächshistorie-Zusammenfassungen. Der System Prompt ist damit weniger ein fester Text als ein Template, das zur Laufzeit befüllt wird.

Für eigene System Prompts heißt das: Templates mit Platzhaltern für dynamische Informationen sind oft robuster als ein langer statischer Text.

6. Gestufte Detailtiefe

Viele Prompts beginnen mit allgemeinen Prinzipien und werden zunehmend spezifischer. Erst den Rahmen setzen, dann Details definieren: Diese Reihenfolge macht Konflikte und Prioritäten besser sichtbar.

Für eigene System Prompts heißt das: Erst Rolle und Prioritäten festlegen, danach Sonderfälle und Formatregeln.

Einen eigenen System Prompt aufbauen

Basierend auf den identifizierten Prinzipien lässt sich ein Template für eigene System Prompts ableiten. Die folgenden Bausteine sind nach Priorität geordnet:

Block 1: Identität und Rolle

Du bist [Name/Rolle]. Du hilfst Nutzern bei [Aufgabenbereich].
Du antwortest auf [Sprache]. Dein Wissensstand ist [Datum].

Die Rollendefinition ist der zentrale Satz im System Prompt. Sie bestimmt den Ton, die Perspektive und die impliziten Annahmen aller folgenden Antworten.

Block 2: Fähigkeiten und Grenzen

Du hast Zugriff auf: [Tool-Liste].
Du kannst: [Fähigkeiten].
Du kannst NICHT: [Einschränkungen].
Wenn du etwas nicht weißt, sage es offen.

Block 3: Verhaltensregeln (allgemein → spezifisch)

Allgemein:
- Antworte sachlich und präzise.
- Belege Aussagen, wo möglich.
Für [Domäne]:
- [Spezifische Regeln]
Priorisierung:
- [Was hat bei Konflikten Vorrang?]

Block 4: Output-Format

Antworte in [Format]. Nutze [Markdown/Listen/Tabellen] wenn sinnvoll.
Halte Antworten unter [Länge], es sei denn, die Komplexität erfordert mehr.

Block 5: Fallback

Wenn du unsicher bist: [Verhalten].
Wenn die Anfrage unklar ist: [Rückfrage stellen / Annahmen benennen].

Die Reihenfolge ist relevant, das Modell gewichtet tendenziell früher genannte Anweisungen stärker. Die wichtigsten Regeln sollten daher am Anfang stehen.

System Prompts sind keine Sicherheitsmechanismen

Ein kritischer Punkt, den die Analyse deutlich macht: System Prompts steuern, aber sie sichern nicht ab. System-Prompt-Anweisungen können durch Prompt Injection unterlaufen werden, ein Problem, das strukturell in der Architektur von LLMs angelegt ist.

Der Artikel Sicherheit von LLMs - Daten gleich Code analysiert dieses Problem im Detail: LLMs verarbeiten System Prompt und Nutzereingabe als Token-Sequenzen im selben Kontext. Die Grenze zwischen "vertrauenswürdiger Anweisung" und "nicht vertrauenswürdiger Eingabe" entsteht nicht allein durch den Text des Prompts, sondern durch Modelltraining, API-Schichten, Tool-Berechtigungen und zusätzliche Schutzmaßnahmen.

Die Konsequenz für die Praxis: System Prompts sind geeignet für: - Verhaltenssteuerung: Ton, Format, Rolle, Fokus - Qualitätsoptimierung: Bessere, konsistentere Antworten - Workflow-Definition: Schrittweises Vorgehen, Tool-Nutzung

Sie sind nicht geeignet als alleiniger Schutz für: - Zugriffskontrolle auf sensible Daten - Verhinderung von Missbrauch - Durchsetzung von Compliance-Regeln

Für diese Zwecke sind zusätzliche technische Maßnahmen außerhalb des Modells erforderlich: Output-Filter, Klassifikatoren, architektonische Constraints.

Fazit

System Prompts sind ein Interface zwischen Betreiber und Modell, also eine Stelle, an der menschliche Absicht in maschinelles Verhalten übersetzt wird. Öffentlich gewordene Prompts zeigen trotz aller Einschränkungen wiederkehrende Muster: explizite Priorisierung, gestufte Detailtiefe, positive Formulierungen und definierte Fallbacks. Diese Prinzipien lassen sich auf eigene Anwendungen übertragen, ob für einen Kundenservice-Bot, eine Code-Review-Pipeline oder einen persönlichen Assistenten. Entscheidend ist weniger die Länge des Prompts als seine klare Struktur, Priorisierung und Einbettung in technische Schutzmaßnahmen.

Wie sich System Prompts in der API technisch umsetzen und in eigene Software integrieren lassen, behandelt der Artikel Prompt Engineering für Entwickler.