# Prompt als Protokoll

> Prompt Engineering in Produktion: KI-Protokoll statt Fliesstext. Structured Outputs, JSON-Schema, Function Calling als Vertrag zwischen Modell und Anwendung.

Veröffentlicht: 2026-08-30

Wer heute über KI spricht, meint Prompts. Wer die produktivsten KI-Workflows baut, spricht über Protokolle. Das ist eine Wortspielerei mit Folgen für das Design der meisten Anwendungen, die in den nächsten Jahren entstehen.

## Auf den Punkt

Für Leser ohne fünfzehn Minuten: ein Prompt ist eine Bitte, ein Protokoll eine Übereinkunft. In Produktion zählt nur die zweite Form. Wer ein KI-System ernst nimmt, definiert zuerst die Ein- und Ausgabe, das Toolset und die Fehlerfälle, bevor das Modell zum ersten Mal angesprochen wird. Der Wechsel von Prompt zu Protokoll ist eine andere Architekturklasse, kein Tuning.

## Glossar

{% definition term="Token" description="Die kleinste Verarbeitungseinheit eines Sprachmodells. Ein Token entspricht ungefähr einem Wort oder Wortteil; ein typischer Absatz besteht aus 50 bis 200 Tokens. Wer ein Protokoll spezifiziert, sollte angeben, in welcher Token-Einheit Limits definiert werden, weil das Modell auf Token-Ebene denkt, nicht auf Wort-Ebene." /%}

{% definition term="JSON-Schema" description="Eine formale Spezifikation der Struktur, die ein JSON-Objekt haben muss. Wer seinem Modell sagt, dass es in JSON antworten soll, sollte zusätzlich das Schema definieren, sonst antwortet das Modell in einer plausibel aussehenden, aber inkonsistenten Variante." /%}

{% definition term="Function Calling" description="Die Fähigkeit eines Modells, anstelle einer Textantwort einen strukturierten Aufruf einer vorher definierten Funktion auszuliefern. Function Calling ist die technische Grundlage für Tool-Use bei modernen Agenten und die Schnittstelle, an der Protokolle zwischen Modell und Anwendung am schärfsten definiert werden müssen." /%}

{% definition term="Embedding" description="Eine Funktion, die einen Text auf einen Vektor mit fester Länge abbildet, sodass semantisch ähnliche Texte nahe beieinander liegen. Embeddings sind Teil des Protokolls, weil sie eine Metrik definieren, und eine Metrik ist keine neutrale Grösse, sondern eine designierte Entscheidung mit Konsequenzen für die Anwendung." /%}

## Die Verwechslung

Ein Prompt ist ein Stück Text in natürlicher Sprache, der ein Modell instruiert. Ein Protokoll ist eine Übereinkunft zwischen zwei Parteien über die Form und Bedeutung der ausgetauschten Nachrichten. Diese Unterscheidung klingt akademisch, hat handfeste Konsequenzen.

Ein Prompt kann alles Mögliche sein: höflich formuliert, schlecht formuliert, vollständig, lückenhaft. Er ist eine **Bitte**. Das Modell kann sie auf unzählige Arten interpretieren, und die meisten werden im konkreten Fall gut genug funktionieren, um den Eindruck zu erwecken, das System sei belastbar.

Ein Protokoll lässt diese Mehrdeutigkeit nicht zu. Es definiert, was eine gültige Anfrage ist, was eine gültige Antwort ist, was bei Fehlern passiert, was im Streitfall gilt. Es ist eine **Übereinkunft**. Das Modell kann sie nicht kreativ interpretieren, ohne gegen den Vertrag zu verstossen.

## Warum die Verschiebung passiert

Wer einmal versucht hat, ein KI-System in eine bestehende Anwendung einzubetten, kennt die Reibung. Das Modell antwortet mal mit JSON, mal mit Fliesstext. Es zitiert mal einen Pfad, mal erfindet es einen. Es hilft, es schadet, es halluziniert, es korrigiert sich. Wer das in einem Prototyp duldet, wird in Produktion scheitern.

Die Reaktion auf diese Reibung war in den letzten zwei Jahren bemerkenswert. Statt "das Modell muss einfach besser werden" haben sich drei Praktiken durchgesetzt, die alle in dieselbe Richtung zielen: das Modell in eine deterministische Hülle einspannen.

1. Strukturierte Ausgaben. Modelle werden angewiesen, ihre Antwort in ein definiertes JSON-Schema zu giessen. Das ist kein Trick, das ist die Implementierung der Annahme "Antwort = Nachricht im Protokoll".
2. Tool-Definitionen. Die Schnittstelle, über die ein Modell Code ausführt oder Daten abruft, wird explizit spezifiziert, mit Argumenten, Rückgabetypen, Fehlercodes. Auch das ist Protokoll, nicht Prompt.
3. Verifikationsschritte. Vor jeder Ausgabe wird geprüft, ob die Antwort dem Protokoll entspricht. Wenn nicht, wird verworfen oder korrigiert. Das ist Prüfsumme, nicht Magie.

Alle drei Praktiken haben denselben semantischen Kern: die Übereinkunft zwischen Mensch und Modell wird explizit gemacht, validierbar, debuggbar. Genau diese Verschiebung ist es, die [agentische Systeme](/posts/agentische-arbeit/) überhaupt erst von Demo-Chatbots unterscheidet.

## Drei Code-Beispiele: schlechter Prompt zum Protokoll

Der Unterschied zwischen Prompt und Protokoll zeigt sich am deutlichsten im Code. Drei Beispiele aus der Praxis, jedes in einer Vorher- und Nachher-Variante.

### Beispiel 1: Strukturierter Output

**Vorher (Prompt):** "Antworte mit dem Namen der Stadt und dem Land, getrennt durch ein Komma."

```text
Berlin, Deutschland
```

Funktioniert für diesen einen Fall. Aber was, wenn die Antwort mehrere Städte enthält? Was, wenn das Land im Modell als "Germany" statt "Deutschland" zurückkommt? Was, wenn das Modell eine Stadt erfindet, die es nicht gibt? Der Konsument dieser Antwort muss raten.

**Nachher (Protokoll):** Ein JSON-Schema, das Felder, Typen und Constraints definiert:

```json
{
  "type": "object",
  "properties": {
    "city": { "type": "string", "minLength": 1 },
    "country": { "type": "string", "pattern": "^[A-Z][a-zäöüß]+$" }
  },
  "required": ["city", "country"],
  "additionalProperties": false
}
```

```json
{ "city": "Berlin", "country": "Deutschland" }
```

Der Konsument liest die Antwort als JSON-Objekt mit typsicherem Zugriff. Er weiss, dass das Land mit Grossbuchstaben anfängt, dass es genau ein Element gibt, dass keine zusätzlichen Felder mitgeliefert werden. Das ist der Unterschied zwischen "scheint zu funktionieren" und "ist spezifiziert", nicht zwischen 99 % und 100 % Korrektheit.

### Beispiel 2: JSON Schema für LLM Outputs und Function Calling statt Freitext-Tool-Aufruf

**Vorher (Prompt):** "Wenn du eine Stadt nachschlagen willst, schreibe 'SUCHEN: <Stadt>'."

```text
SUCHEN: Berlin
```

Das Modell muss diese Konvention erlernen und einhalten. Wenn es "Suchen" statt "SUCHEN" schreibt, den Doppelpunkt vergisst, zusätzlichen Text mitschickt, bricht die Anwendung. Der Parser wird fehlertolerant, und die Anwendung komplexer statt einfacher.

**Nachher (Protokoll):** Eine Tool-Definition mit Argumenten und Rückgabewert:

```json
{
  "name": "lookup_city",
  "description": "Schlägt eine Stadt in der Wissensdatenbank nach",
  "parameters": {
    "type": "object",
    "properties": {
      "city": { "type": "string" }
    },
    "required": ["city"]
  }
}
```

Der Aufruf erfolgt strukturiert, der Parser liest typsicher, der Konsument sieht, welches Werkzeug mit welchen Argumenten aufgerufen wurde. Keine String-Konventionen, keine Parser-Toleranz, keine Mehrdeutigkeit. Diese Form ist auch die Grundlage für jede Form von Tool-Use in [agentischen Architekturen](/posts/agentische-arbeit/).

### Beispiel 3: Fehlerfall

**Vorher (Prompt):** "Wenn du die Antwort nicht weisst, sag 'unbekannt'."

```text
unbekannt
```

Was passiert, wenn das Modell "Unbekannt" schreibt, mit Grossbuchstaben? Oder "I don't know"? Oder einen langen Erklärtext, der irgendwo das Wort "unbekannt" enthält? Der Konsument muss raten, was die Antwort bedeutet. Er weiss nicht, ob das Modell ratlos war oder aus Höflichkeit eine Antwort konstruiert hat.

**Nachher (Protokoll):** Ein strukturiertes Fehlerverhalten:

```json
{
  "oneOf": [
    { "type": "object", "required": ["status", "data"], "properties": {
      "status": { "const": "ok" },
      "data": { "type": "string" }
    }},
    { "type": "object", "required": ["status", "reason"], "properties": {
      "status": { "const": "unknown" },
      "reason": { "type": "string", "enum": ["not_in_kb", "ambiguous_query", "filtered"] }
    }}
  ]
}
```

Der Konsument liest `status: "unknown"` und `reason: "not_in_kb"` und kann darauf programmatisch reagieren, eine andere Antwort anzeigen, eine Eskalation einleiten, einen Log schreiben. Das Modell wird nicht mit Mehrdeutigkeit allein gelassen, weil das Protokoll die Wahl zwischen "Antwort" und "Fehler" explizit macht.

Diese drei Beispiele haben eines gemeinsam: sie ersetzen eine Annahme ("das Modell wird es schon richtig machen") durch eine Spezifikation ("das Modell antwortet in genau dieser Form"). Der Aufwand ist beim ersten Mal höher. Die Stabilität über die Lebenszeit des Systems ist um Grössenordnungen besser, und dieser Unterschied entscheidet, ob ein System die nächste [Modell-Drift](/posts/modell-drift/) überlebt.

## Das verborgene Protokoll

Auch in Systemen, die ihre Anwender als "Prompt-basiert" verkaufen, existieren Protokolle. Sie sind nur häufig implizit, schwer zu finden und schwer zu ändern.

Ein klassisches Beispiel ist ein Chatbot, der im Systemprompt eines Drittanbieters steht und dessen Verhalten subtil von der Version des Anbieters abhängt. Wer das System nutzt, hat ein Protokoll, das er nicht sieht und nicht kontrolliert. Das ist, als würde man eine API nutzen, deren Spezifikation sich monatlich ändert, ohne dass die Changelog-Pflicht besteht.

Ein anderes Beispiel sind Embeddings. Ein Embedding ist eine Funktion vom Text auf einen Vektor. Wer diese Funktion nutzt, hat eine Metrik definiert, nach der zwei Texte ähnlich sind oder nicht. Diese Metrik ist Teil des Protokolls, und doch wird sie selten so behandelt. Sie wird benutzt, als wäre sie neutral, als spräche sie für sich selbst. Tut sie nicht.

{% definition term="Protokoll" description="Eine explizite Übereinkunft zwischen Sender und Empfänger über das Format, die Bedeutung und die Fehlerfälle der ausgetauschten Nachrichten." /%}

Die produktivsten Teams, die ich in den letzten Monaten beobachtet habe, haben angefangen, ihre impliziten Protokolle explizit zu machen. Sie dokumentieren die Annahmen, die ihre Prompts über das Modell machen. Sie fragen "welche Form von Austausch ist hier sinnvoll", nicht "welcher Prompt funktioniert".

## Drei Fragen, die den Unterschied machen

Wer ein KI-System entwirft, kann drei Fragen stellen, die den Wechsel vom Prompt zum Protokoll erzwingen. Sie klingen banal, sind aber selten beantwortet.

**Was genau ist die Eingabe?** Nicht "der Text des Users", sondern: in welcher Form kommt er an, welche Felder sind erforderlich, welche optional, was passiert, wenn ein Feld fehlt oder fehlerhaft ist. Wer diese Frage beantwortet, hat ein DTO-Design. Wer sie nicht beantwortet, hat einen Prompt.

**Was genau ist die Ausgabe?** Nicht "die Antwort des Modells", sondern: in welcher Struktur kommt sie zurück, welche Felder sind Pflicht, welche können fehlen, was ist der Unterschied zwischen einer leeren und einer verweigerten Antwort. Wer diese Frage beantwortet, hat eine Spezifikation. Wer sie nicht beantwortet, hat einen Wunsch.

**Was passiert im Fehlerfall?** Nicht "das Modell merkt das schon", sondern: was geschieht, wenn das Modell die Anfrage nicht versteht, das Tool nicht aufrufen kann, die Antwort unvollständig zurückkommt. Wer diese Frage beantwortet, hat ein stabileres System. Wer sie nicht beantwortet, hat ein Glücksspiel.

## Vier Ebenen: Prompt, Vertrag, Protokoll, Gesetz

{% bar-horizontal caption="Vier Ebenen steigender Verbindlichkeit. Wer ein KI-System entwirft, sollte wissen, auf welcher Ebene es gerade steht." data="{\"items\":[{\"label\":\"Prompt\",\"value\":1},{\"label\":\"Vertrag\",\"value\":2},{\"label\":\"Protokoll\",\"value\":3},{\"label\":\"Gesetz\",\"value\":4}],\"max\":4}" /%}

Wer die Verschiebung vom Prompt zum Protokoll verstehen will, profitiert von einer Einordnung in vier Ebenen, die in der Rechts- und Software-Welt seit langem etabliert sind.

**Prompt** ist eine freundliche Bitte ohne Verbindlichkeit. **Vertrag** ist beidseitig und freiwillig, etwa ein API-SLA zwischen Anbieter und Kunde. **Protokoll** ist technisch und automatisiert prüfbar, ein JSON-Schema, eine Tool-Definition, ein Verifikationsschritt. **Gesetz** ist die externe Autorität mit gerichtlicher Durchsetzung, die DSGVO, der AI Act, die jeweilige Branchenregulierung.

Diese Reihenfolge ist nicht vollständig, die Übergänge sind fliessend, und nicht jedes System braucht alle vier Ebenen. Aber sie zeigt die Verschiebung: ein KI-Workflow beginnt auf der Prompt-Ebene und muss in die Protokoll-Ebene gehoben werden, sobald er eine andere Komponente berührt. Wer auf der Prompt-Ebene bleibt, hat eine Demo. Wer die Protokoll-Ebene erreicht, hat ein Produkt. Wer die Gesetz-Ebene ignoriert, hat einen Vorfall.

In der Praxis ist es hilfreich, beim Design eines neuen KI-Workflows die Frage zu stellen: auf welcher Ebene befindet sich dieses System gerade? Die Antwort entscheidet, welche Disziplin investiert werden muss. Eine Demo darf Prompt sein. Eine API muss Protokoll sein. Eine Funktion im regulierten Umfeld muss Protokoll plus Audit-Trail sein, und das ist der Punkt, an dem die Vertrags- und Gesetz-Ebenen ins Spiel kommen.

## Die Ironie der Kreativität

Es gibt eine Ironie in dieser Verschiebung. KI-Modelle werden populär, weil sie kreativ sind. Sie antworten auf eine Bitte mit etwas, das du nicht erwartet hast. Sie finden einen Pfad, den du nicht kanntest. Genau das macht sie wertvoll.

Ein Protokoll begrenzt diese Kreativität. Es definiert, was eine gültige Antwort ist, und schliesst alles andere aus. Das ist ein Verlust, der sich nicht wegdiskutieren lässt.

Die produktive Frage lautet deshalb: an welcher Stelle des Workflows brauche ich welches Verhalten? Am Anfang eines Prozesses, beim Sammeln von Kontext oder beim Brainstorming, ist Kreativität erwünscht. Am Ende, beim Schreiben einer Datei oder beim Antworten an einen User, ist Vorhersagbarkeit erwünscht. Wer diese Unterscheidung macht, baut Systeme, die beides können.

## Was ein gutes KI-Protokoll von einem schlechten unterscheidet

Nicht jedes Protokoll ist gleich viel wert. Wer mit der Methode anfängt, stellt bald fest, dass es gute und schlechte Protokolle gibt, und dass der Unterschied selten in der Grosszügigkeit der Felder liegt, sondern in der Disziplin der Grenzen. Vier Heuristiken, die sich in der Praxis bewährt haben.

Versionierung ist nicht optional. Ein Protokoll ohne Version ist eine aktuelle Meinung, kein Protokoll. Wer ein modell-basiertes System betreibt, sollte jede Änderung an Schema, Tool-Definition oder Fehlercodes mit einer Versionsnummer versehen und die Migration dokumentieren. Klingt nach Overhead, ist aber die einzige Möglichkeit, einen Bug zu reproduzieren, der drei Monate alt ist.

Ein Protokoll ohne dokumentierte Fehlerfälle ist unvollständig. Jeder Endpunkt, jede Antwort, jeder Tool-Aufruf braucht ein dokumentiertes Fehlerverhalten: was passiert, wenn die Eingabe leer ist, wenn das Modell die Anfrage ablehnt, wenn ein Tool timeoutet. Wer das beim ersten Entwurf weglässt, schreibt es später unter Druck, und dann fehlen die Felder, die am dringendsten gebraucht werden.

Beispielantworten sind Teil der Spezifikation. Wer ein Protokoll spezifiziert, sollte eine konkrete Beispielantwort liefern, die alle Pflichtfelder zeigt und alle Edge-Cases illustriert. Diese Beispielantwort ist die Referenz, gegen die jede reale Antwort geprüft wird. Wer nur das Schema dokumentiert, lässt die Interpretation dem Modell über, und das Modell interpretiert grosszügig.

Der Vertrag wird mit dem Modell geschlossen, nicht für es. Das ist die subtilste und wichtigste Regel. Wer ein Protokoll schreibt, schreibt es aus der Perspektive des Anrufers. Das Modell ist Empfänger und Interpret in einer Person. Ein Protokoll, das die Perspektive des Modells ignoriert, wird vom Modell nicht verlässlich eingehalten, weil es seine Eigenheiten nicht berücksichtigt. Wer ein Protokoll schreibt, muss verstehen, wie das Modell Anweisungen liest, welche Formulierungen es anders deutet als ein Mensch, und an welchen Stellen seine Aufmerksamkeit typischerweise nachlässt.

Diese vier Heuristiken sind keine Checkliste für ein neues System. Sie sind die Erfahrung aus Dutzenden von Iterationen über die letzten zwei Jahre. Wer sie befolgt, baut Systeme, die bei jeder Modell-Iteration anpassbar bleiben. Wer sie ignoriert, baut Systeme, die bei jedem Modell-Update neu justiert werden müssen.

## Was das für die Praxis bedeutet

Wer ein KI-Projekt startet, sollte die erste Woche nicht mit Prompt-Iteration verbringen. Die Ein- und Ausgabe werden definiert, das Toolset festgelegt, die Fehlerfälle aufgeschrieben. Erst danach lohnt es sich, mit dem Modell zu sprechen. Diese Reihenfolge fühlt sich für viele Entwickler langsamer an. Sie ist es nicht, sie erspart die drei Wochen, die sonst in "warum antwortet das Modell manchmal so und manchmal anders" versenkt werden, und sie bildet die Grundlage, auf der [Tail-Risiken](/posts/tail-risk-ki/) überhaupt erst budgetierbar werden.

Ein letzter Punkt, weil er gerne vergessen wird: Protokolle sind nicht starr. Sie sind ein laufendes Dokument, das mit jeder Beobachtung am System wächst. Was am Anfang eine Annahme war, wird nach dem ersten Bugfall eine Klausel. Was am Anfang eine Klausel war, wird nach dem hundertsten Edge-Case eine Migration. Wer das akzeptiert, baut kein KI-System, sondern ein Produkt.

{% questionAnswer question="Wann reicht ein Prompt?" answer="Im Prototyp und im Gespräch mit dem Modell selbst. Sobald das Ergebnis eine andere Komponente erreicht, eine UI, eine Datenbank, einen anderen Service, wird daraus ein Protokoll." /%}

## Weiterführend

- **[Structured model outputs](https://developers.openai.com/api/docs/guides/structured-outputs)** (OpenAI Platform), die ausführlichste öffentliche Dokumentation zur Frage, wie Modelle typsichere Ausgaben erzeugen. Empfehlenswert vor allem für die Diskussion von JSON-Schema-Constraints und ihre Grenzen.
- **[Tool Use with Claude](https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/overview)** (Anthropic Docs), eine andere Variante desselben Themas, mit konkreten Beispielen für Tool-Definitionen und Verifikationsstrategien.
- **[JSON Schema](https://json-schema.org/)** (json-schema.org), wer ein eigenes Protokoll spezifiziert, kommt um diese Spezifikation nicht herum. Liest sich trocken, ist aber die Grundlage, auf der jedes typsichere Modell-Output-Setup aufsetzt.