Strukturierte Ausgaben mit KI und JSON: So werden Workflows stabiler

KI-Ausgaben werden erst dann zu verlässlichen Workflow-Ergebnissen, wenn nachfolgende Systeme sie eindeutig verarbeiten können. Freitext ist für Menschen oft verständlich, für Software aber mehrdeutig: Ein Status kann unterschiedlich formuliert sein, ein Pflichtfeld fehlen oder eine Begründung an der falschen Stelle stehen. Strukturierte Ausgaben mit KI und JSON verringern diese Unsicherheit. Sie legen fest, welche Felder ein Ergebnis enthält und welche Werte zulässig sind. Für Geschäftsführung, Produktverantwortliche und technische Leitung ist die entscheidende Frage deshalb nicht nur, ob ein Modell JSON erzeugt. Entscheidend ist, ob ein Schema zum Prozess passt, die Ausgabe zuverlässig geprüft wird und Fehler kontrolliert behandelt werden. JSON macht KI nicht automatisch korrekt. Es schafft aber eine belastbare Schnittstelle zwischen probabilistischer Textgenerierung und deterministischer Softwarelogik.

Kurz gesagt

Ein JSON-Objekt mit beliebigen Feldern ist noch keine verlässliche strukturierte Ausgabe. Dafür braucht es ein Schema, das Pflichtfelder, Datentypen und erlaubte Werte festlegt. Die Anwendung muss jede Antwort unabhängig prüfen und ungültige Ergebnisse begrenzt erneut anfordern oder zur Prüfung weiterleiten. Strukturierte Ausgabe verbessert die Verarbeitbarkeit, nicht automatisch die inhaltliche Wahrheit.

Ausgangslage

Ein Freitext-Ergebnis verlangt oft weitere Interpretationsarbeit. Ein nachgelagerter Schritt muss erkennen, ob „freigeben“, „kann veröffentlicht werden“ und „approve“ dasselbe bedeuten. Selbst wenn die KI meist die erwartete Formulierung verwendet, reicht eine abweichende Antwort, um eine Automatisierung zu unterbrechen oder eine falsche Verzweigung auszulösen.

JSON löst einen Teil dieses Problems, weil es Daten in einer maschinenlesbaren Struktur ausdrückt. Es kann zum Beispiel einen Status als festgelegten Wert, eine Begründung als Text und Belege als Liste getrennt abbilden. Doch gültiges JSON kann fachlich unvollständig, widersprüchlich oder falsch sein. Ein Parser prüft die Syntax. Ein Schema prüft die vereinbarte Form. Keine dieser Prüfungen bestätigt für sich genommen, dass eine Aussage stimmt oder eine Entscheidung angemessen ist.

Die sinnvolle Grenze verläuft daher nicht zwischen „Freitext“ und „JSON“, sondern zwischen einer unkontrollierten Ausgabe und einem definierten Vertrag zwischen Modell und Anwendung. Dieser Vertrag beschreibt, was die Anwendung erwartet und wie sie mit Abweichungen umgeht.

Entscheidungskriterien

1. Welche Entscheidung soll die Ausgabe ermöglichen?

Leiten Sie das Schema aus dem nächsten Prozessschritt ab, nicht aus dem, was das Modell leicht erzeugen kann. Muss ein Inhalt einer Redaktion zur Freigabe vorgelegt werden, braucht das System beispielsweise einen eindeutigen Bearbeitungsstatus. Soll ein Datensatz ergänzt werden, müssen die Felder so definiert sein, dass sie in das vorhandene Datenmodell passen.

Jedes Feld sollte einen klaren Zweck haben. Wenn ein nachgelagerter Schritt eine Information nicht nutzt, muss sie nicht zwingend Teil der Ausgabe sein. Ein zu umfangreiches Schema vergrößert die Zahl möglicher Fehler und macht Änderungen schwerer.

2. Welche Werte sind zulässig?

Freie Zeichenketten eignen sich für Begründungen, Zusammenfassungen oder Hinweise. Für Status, Kategorie und andere steuernde Felder sind festgelegte Werte meist robuster. Statt den Status frei formulieren zu lassen, kann das Schema etwa nur approve, revise oder reject erlauben.

Prüfen Sie auch, ob ein Feld fehlen darf, leer sein darf oder ausdrücklich null sein kann. Diese Fälle sind nicht gleichbedeutend. Wenn „unbekannt“ eine relevante Information ist, sollte sie als eigener Zustand modelliert werden, statt sie durch eine erfundene Annahme zu ersetzen.

3. Welche Regeln kann das Schema prüfen?

Ein Schema kann Datentypen, Pflichtfelder, erlaubte Werte und zusätzliche Felder kontrollieren. Es kann aber keine komplexe fachliche Plausibilität garantieren. Ob ein Datum im Kontext richtig ist, ob ein Beleg die Aussage wirklich stützt oder ob zwei Textpassagen einander widersprechen, braucht zusätzliche Logik oder menschliche Prüfung.

Ein kompaktes Schema für eine allgemeine redaktionelle Prüfung könnte so aussehen:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "additionalProperties": false,
  "required": ["decision", "reason", "evidence"],
  "properties": {
    "decision": {
      "type": "string",
      "enum": ["approve", "revise", "reject"]
    },
    "reason": { "type": "string", "minLength": 1 },
    "evidence": {
      "type": "array",
      "items": { "type": "string" }
    }
  }
}

Das Beispiel ist ein allgemeines Muster, keine Beschreibung eines konkreten Projektschemas. additionalProperties: false verhindert unerwartete Felder; die enum-Regel begrenzt den Status auf drei Werte. Die Prüfung sagt jedoch nicht, ob die Begründung oder die genannten Belege inhaltlich tragfähig sind.

4. Wie kritisch ist ein Fehler?

Bei einer internen Zusammenfassung kann eine ungültige Ausgabe zunächst in eine manuelle Prüfung laufen. Wenn die KI dagegen Berechtigungen, Veröffentlichungen oder Transaktionen beeinflusst, muss die Anwendung deutlich strengere Grenzen setzen. Eine Modellantwort sollte nicht selbst darüber entscheiden, ob sie ihre eigenen Sicherheits- oder Freigaberegeln umgehen darf.

Legen Sie vor der Umsetzung fest, welche Fehler automatisch behoben werden dürfen, welche eine erneute Anfrage auslösen und welche den Workflow stoppen. Je größer die mögliche Auswirkung, desto weniger sollte die Anwendung auf eine ungeprüfte Modellausgabe vertrauen.

5. Wie ändern sich Schema und Prozess?

Ein Schema ist Teil der Schnittstelle. Wird ein Feld umbenannt oder ein erlaubter Wert entfernt, können damit verbundene Prompts, Validierungen und nachgelagerte Systeme brechen. Versionieren Sie relevante Änderungen und prüfen Sie, welche Workflow-Schritte davon abhängen. Bei gewachsenen Prozessen ist die Frage, wer ein Schema ändern und freigeben darf, ebenso wichtig wie seine technische Definition.

Vorgehen: Ausgabe, Prüfung, Behandlung

Ein belastbarer Ablauf trennt drei Aufgaben: Das Modell erzeugt einen Vorschlag, die Anwendung prüft die Form, und der Prozess entscheidet über die weitere Verwendung. Wo verfügbar, kann eine API die Ausgabe an ein Schema binden. Trotzdem sollte das System die empfangenen Daten selbst validieren: Modellvorgaben ersetzen keine Prüfung an der eigenen Systemgrenze.

Nach der Antwort sollte die Anwendung zunächst prüfen, ob sich die Ausgabe parsen lässt und dem Schema entspricht. Anschließend folgen fachliche Prüfungen. Das können Regeln in der Software sein, etwa eine erlaubte Kategorie oder eine Referenz auf einen tatsächlich vorhandenen Datensatz. Bei redaktionellen Inhalten kann die Anwendung zusätzlich kennzeichnen, welche Aussagen eine menschliche Prüfung benötigen.

Wenn die Antwort ungültig ist, sollte die Wiederholung gezielt und begrenzt erfolgen. Geben Sie dem Modell die konkrete Abweichung zurück, etwa ein fehlendes Pflichtfeld oder einen nicht erlaubten Status, und fordern Sie eine Korrektur im vorgegebenen Format an. Eine identische Wiederholung ohne Fehlerhinweis behebt die Ursache nicht zuverlässig. Nach einer festgelegten Zahl von Versuchen sollte der Workflow stoppen oder die Ausgabe in eine Prüfschleife geben.

Unterscheiden Sie dabei zwischen technischen und fachlichen Fehlern. Ungültiges JSON oder ein falscher Datentyp kann eine korrigierte Modellanfrage rechtfertigen. Eine unbelegte Tatsachenbehauptung lässt sich dagegen nicht dadurch absichern, dass sie erneut als gültiges JSON ausgegeben wird. Sie braucht eine verlässliche Quelle, eine andere Prüflogik oder eine menschliche Entscheidung.

Speichern Sie für die Fehlersuche mindestens die verwendete Schema-Version, den Validierungsstatus und den Grund für eine Wiederholung oder Übergabe. Welche Eingaben und Modellantworten gespeichert werden dürfen, muss im jeweiligen Datenschutz- und Sicherheitskontext geprüft werden. Die Protokollierung sollte dem Zweck dienen, Fehler nachzuvollziehen, nicht ungeprüft möglichst viele Inhalte sammeln.

Praxisbeispiel

Bei Ting antworten mehrere KI-Anbieter unabhängig voneinander. Die Ergebnisse werden strukturiert als approve, revise oder reject abgestimmt; eine Freigabe erfolgt nur bei Einstimmigkeit. Strukturierte Ausgaben machen diese Statuswerte für den Abstimmungsprozess vergleichbar. Sie ersetzen aber nicht die fachliche Prüfung: Der Prozess kombiniert die festgelegte Ausgabeform mit einer klaren Freigaberegel. Ting nutzt außerdem PostgreSQL mit pgvector als Gedächtnis und strukturierte Ausgaben per Schema. Mehr zu Ting.

Für eine Redaktionspipeline gilt dasselbe Prinzip. Eine KI kann einen Entwurf oder eine Prüfung strukturiert zurückgeben, zum Beispiel mit Status, Begründung und Hinweisen. Das System kann diese Angaben dann einer Redaktion zur Freigabe vorlegen. Die Veröffentlichung sollte aber an eine explizite redaktionelle Entscheidung gebunden bleiben, wenn der Prozess diese Kontrolle verlangt. Strukturierte Daten erleichtern den Übergang zwischen Schritten; sie machen aus einer Textgenerierung nicht automatisch eine Publikationsentscheidung.

Typische Fehler

• JSON mit Schema verwechseln. Syntaktisch gültige Objekte können Pflichtinformationen vermissen lassen oder unerlaubte Werte enthalten.
• Zu viele Felder verlangen. Felder ohne klaren Prozessnutzen erhöhen die Komplexität, ohne die Entscheidung zu verbessern.
• Freie Texte als Steuerwerte verwenden. Wenn ein Status einen Workflow-Zweig auslöst, sollte er nicht von variabler Formulierung abhängen.
• Validierung nur im Prompt erledigen. Eine Anweisung an das Modell ist keine Prüfung durch die Anwendung.
• Formale Gültigkeit als Wahrheitsnachweis behandeln. Ein Schema prüft Struktur, nicht automatisch Fakten oder Qualität.
• Unbegrenzt wiederholen. Wiederholungen ohne klare Abbruchregel können Fehler verschleiern und den Ablauf unnötig verlängern.
• Fehler stillschweigend überspringen. Wenn ein Datensatz nicht verarbeitet werden kann, muss der Prozess sichtbar stoppen, zurückweisen oder an eine zuständige Person übergeben.
• Änderungen am Schema nicht nachverfolgen. Eine unkoordinierte Änderung kann verbundene Workflows und gespeicherte Daten unbrauchbar machen.

Empfehlung

Wenn die Ausgabe einen klar abgegrenzten nächsten Schritt steuert, definieren Sie zuerst die dafür benötigten Felder und begrenzten Werte. Validieren Sie jede Antwort in der Anwendung und legen Sie eine begrenzte, fehlerbezogene Wiederholung fest.

Wenn die Aufgabe überwiegend offene Analyse oder Textarbeit ist, sollte Freitext nicht künstlich in ein starres Schema gezwängt werden. Strukturieren Sie nur die Informationen, die ein nachfolgender Prozess tatsächlich braucht, und behalten Sie den übrigen Inhalt als Text.

Wenn eine ungültige oder falsche Ausgabe spürbare Folgen haben kann, stoppen Sie den Workflow bei nicht behebbaren Fehlern und sehen Sie eine menschliche Freigabe vor. Wenn sich Schema und Prozess häufig ändern, behandeln Sie die Ausgabeform als versionierte Schnittstelle und testen Sie abhängige Schritte bei jeder Änderung.

Checkliste

• Ist klar, welche konkrete Entscheidung oder Verarbeitung auf die KI-Ausgabe folgt?
• Enthält das Schema nur Felder mit einem definierten Zweck?
• Sind Pflichtfelder, Datentypen und erlaubte Werte festgelegt?
• Ist eindeutig geregelt, wann ein Feld fehlen, leer oder null sein darf?
• Prüft die Anwendung die Ausgabe unabhängig vom Prompt?
• Sind formale und fachliche Prüfungen voneinander getrennt?
• Ist die Zahl der Wiederholungen begrenzt und wird der Fehler gezielt zurückgemeldet?
• Gibt es einen klaren Abbruch- oder Übergabepfad für nicht behebbare Fehler?
• Werden Schemaänderungen versioniert und verbundene Workflow-Schritte getestet?
• Ist festgelegt, wann eine Person die Ausgabe prüfen oder freigeben muss?

Häufige Fragen

Macht JSON KI-Ausgaben automatisch zuverlässig?

Nein. JSON erleichtert die maschinelle Verarbeitung. Erst Schema- und Fachprüfungen sowie eine passende Fehlerbehandlung machen daraus einen kontrollierten Workflow.

Reicht ein Prompt mit der Anweisung „Antworte nur als JSON“?

Nein. Die Anweisung beeinflusst die Ausgabe, garantiert aber keine gültige oder vollständige Antwort. Prüfen Sie die Antwort in der Anwendung und nutzen Sie, wenn verfügbar, zusätzlich eine schema-gebundene Ausgabe der API.

Sollte jede KI-Aufgabe ein festes Schema haben?

Nein. Ein Schema lohnt sich besonders, wenn nachfolgende Software Felder auswertet oder Entscheidungen davon abhängen. Für offene Ideenfindung oder freie Textentwürfe kann ein starres Format unnötig einschränken.

Weiterführend

• KI-Automatisierung im Unternehmen
• KI-Workflows richtig testen
• Human-in-the-loop: Warum gute KI-Workflows Menschen nicht entfernen
• KI-Content ohne Blindflug: Research, Entwurf, Prüfung, Freigabe

Weiterführende Quellen

Diese offiziellen Dokumentationen und Standards vertiefen die behandelten Themen.

• OpenAI: Structured Outputs
• Anthropic Dokumentation