Jede Konversation mit ChatGPT, Claude oder Gemini beginnt mit Text, den der Nutzer nie zu sehen bekommt. Bevor die erste Nachricht verarbeitet wird, erhält das Modell einen System Prompt - eine Anweisung, die festlegt, wer es ist, was es kann, was es nicht tun soll und wie es antworten soll. Dieser unsichtbare Prolog bestimmt maßgeblich 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 und gezielte Extraktion sind die System Prompts der großen Anbieter in den letzten Jahren öffentlich geworden. Was dabei zum Vorschein kommt, ist aufschlussreich, nicht nur für das Verständnis der Systeme selbst, sondern als Beispiel für gutes Prompt-Design. Dieser Artikel analysiert die gemeinsamen Muster und Designprinzipien und zeigt, welche Erkenntnisse sich auf eigene Anwendungen übertragen lassen.
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 erlerntes Verhalten. Ein wichtiger Unterschied, auf den der Abschnitt zu Sicherheit zurückkommt.
System Prompt vs. User Prompt vs. Kontext
Die Abgrenzung ist in der Praxis weniger scharf als in der Theorie:
| Aspekt | System Prompt | User Prompt |
|---|---|---|
| Sichtbarkeit | Unsichtbar für den Nutzer | Vom Nutzer geschrieben |
| Persistenz | Gilt für die gesamte Konversation | Gilt für eine Nachricht |
| Zweck | Verhalten definieren | Aufgabe stellen |
| Autorität | Höher priorisiert | Niedriger priorisiert |
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
Die System Prompts von ChatGPT, Claude, Copilot und Gemini sind durch verschiedene Wege ö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.
Gemeinsamer Aufbau
Trotz unterschiedlicher Länge und Detailtiefe folgen alle analysierten System Prompts einer bemerkenswert ähnlichen Grundstruktur. Sie lassen sich in fünf wiederkehrende Bausteine zerlegen:
1. Identität und Wissenstand
Jeder System Prompt beginnt mit einer Selbstbeschreibung: Wer bin ich? Was ist mein Wissensstand? Welches Datum haben wir? Diese Festlegung ist technisch 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, wenn es ihm gesagt wird.
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 stehen zur Verfügung? Kann das Modell Bilder generieren, Code ausführen, im Web suchen? Ebenso wichtig: Was kann es nicht?
Auffällig ist die Explizitheit: Statt dem Modell zu vertrauen, seine Fähigkeiten selbst korrekt einzuschätzen, werden sie aufgezählt. Ein Modell, dem gesagt wird "Du kannst keine Bilder sehen", wird Bildanfragen ablehnen, selbst wenn es technisch (multimodal) möglich wäre. Die Konfiguration übersteuert die vorhandene Fähigkeit.
3. Verhaltensregeln
Der umfangreichste Block in allen analysierten Prompts. Hier werden Hunderte von Verhaltensregeln definiert, 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 bemerkenswert. Die Anbieter haben offensichtlich festgestellt, dass allgemeine Prinzipien nicht ausreichen. Das Vorgehen entspricht dem Few-Shot-Ansatz aus dem Prompt Engineering.
4. Output-Formatierung
Alle Prompts enthalten Anweisungen zur Formatierung der Ausgabe: Wann Markdown verwenden? Wie lang soll eine Antwort sein? Wann Listen, wann Fließtext? Wann 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 der 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 über Regeln. Statt Einzelfälle aufzuzählen, werden übergreifende Werte formuliert, aus denen das Modell Einzelfallentscheidungen ableiten soll. Der Ansatz ist stärker prinzipienbasiert, mit expliziter Aufforderung zum eigenständigen Abwägen. Anthropic ist der einzige große Anbieter, der die System Prompts offiziell veröffentlicht und die dahinterliegende Philosophie in der Claude Model Spec dokumentiert.
Google (Gemini)
Google integriert Tool-Definitionen und Fähigkeiten stärker in den System Prompt. Die Grenze zwischen "Was bin ich?" und "Was kann ich?" ist fließender, was die enge Integration mit Google-Diensten widerspiegelt. Geleakte Gemini-Prompts zeigen diese Verschmelzung von Verhaltensanweisungen und Tool-Konfiguration.
Diese Unterschiede sind nicht nur technische Details, sie spiegeln unterschiedliche Philosophien der KI-Sicherheit wider. Der regelbasierte Ansatz ist deterministischer, aber brüchig bei unvorhergesehenen Szenarien. Der prinzipienbasierte Ansatz ist flexibler, aber weniger vorhersagbar. In der Praxis konvergieren die Ansätze: Alle Anbieter nutzen eine Mischung aus beiden.
Abgeleitete Designprinzipien
Aus der Analyse lassen sich sechs Designprinzipien destillieren, die alle großen Anbieter teilen:
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.
Übertragbar:In eigenen System Prompts explizit definieren, was bei widersprüchlichen Anforderungen Vorrang hat.
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.
Übertragbar:Immer definieren, was passieren soll, wenn die primären Vorgaben keine klare Anweisung enthalten.
3. Positive statt negative Formulierung
Wirksame Regeln beschreiben gewünschtes Verhalten, nicht verbotenes. "Antworte sachlich und belege Aussagen" funktioniert besser als "Halluziniere nicht". Negative Anweisungen können paradoxerweise das unerwünschte Verhalten verstärken, weil das Modell das Konzept aktiviert, das es vermeiden soll, ein Phänomen, das auch in der menschlichen Psychologie bekannt ist.
Übertragbar:Gewünschtes Verhalten beschreiben statt Listen von Verboten.
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.
Übertragbar:Regeln an Kontexte binden statt pauschal formulieren.
5. Dynamische Injektion
Kein System Prompt ist vollständig statisch. Alle 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.
Übertragbar:System Prompts als Templates mit Platzhaltern für dynamische Informationen konzipieren.
6. Gestufte Detailtiefe
Die Prompts beginnen mit allgemeinen Prinzipien und werden zunehmend spezifischer. Erst den Rahmen setzen, dann Details definieren - das entspricht der Art, wie Menschen Anweisungen am besten verarbeiten, und es scheint auch für LLMs zu funktionieren.
Übertragbar:System Prompts von allgemein nach spezifisch aufbauen.
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. Jede Anweisung im System Prompt kann durch geschickte Nutzereingaben umgangen werden, ein Problem, das strukturell in der Architektur von LLMs begründet liegt.
Der Artikel Sicherheit von LLMs - Daten gleich Code analysiert dieses Problem im Detail: LLMs verarbeiten System Prompt und Nutzereingabe als identische Token-Sequenzen. Es gibt keine technische Grenze zwischen "vertrauenswürdiger Anweisung" und "nicht vertrauenswürdiger Eingabe", nur eine Konvention, die das Modell im Training gelernt hat und die es brechen kann.
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 das Interface zwischen Betreiber und Modell, also die Stelle, an der menschliche Absicht in maschinelles Verhalten übersetzt wird. Die Analyse geleakter Prompts zeigt, dass die großen Anbieter trotz unterschiedlicher Philosophien zu ähnlichen Lösungen greifen: explizite Priorisierung, gestufte Detailtiefe, positive Formulierungen und definierte Fallbacks. Diese Prinzipien sind direkt übertragbar, ob für einen Kundenservice-Bot, eine Code-Review-Pipeline oder einen persönlichen Assistenten. Der Schlüssel liegt nicht in der Länge des Prompts, sondern in seiner Struktur.
Wie sich System Prompts in der API technisch umsetzen und in eigene Software integrieren lassen, behandelt der Artikel Prompt Engineering für Entwickler.