JSON Prompt Engineering: Strukturierte Prompts für KI

JSON Prompt Engineering hilft dir, Informationen für KI-Modelle klar zu strukturieren und Antworten maschinell weiterzuverarbeiten. Besonders wertvoll ist das bei Datenextraktion, Klassifizierung, Formularen, API-Workflows und AI Agents. Ein sauber definiertes Format reduziert Missverständnisse und macht Ergebnisse leichter prüfbar.

Dabei werden drei Ansätze häufig vermischt: JSON als Bestandteil eines Prompts, eine im Chat angeforderte JSON-Antwort und technisch erzwungene Structured Outputs über eine API. Sie sehen ähnlich aus, bieten aber sehr unterschiedliche Zuverlässigkeit. In diesem Leitfaden lernst du die Unterschiede, entwickelst ein belastbares JSON Schema und setzt strukturierte KI-Ausgaben in realistischen Unternehmensprozessen ein.

Kurzantwort: Bei JSON Prompt Engineering werden Aufgabe, Eingabedaten, Regeln und gewünschtes Ausgabeformat strukturiert beschrieben. Für Experimente im Chat reicht oft eine klare JSON-Vorlage. Produktive Anwendungen sollten Structured Outputs oder striktes Function Calling mit JSON Schema verwenden und das Ergebnis zusätzlich fachlich validieren. Gültiges JSON garantiert eine korrekte Struktur, aber noch keine korrekten Inhalte.

Aktualisiert am 25. August 2026. Der Artikel berücksichtigt die aktuellen Structured-Output-Funktionen von OpenAI, Google Gemini und Anthropic Claude.

Was ist JSON Prompt Engineering?

JSON steht für JavaScript Object Notation. Das Format organisiert Daten in Schlüssel-Wert-Paaren, Arrays und verschachtelten Objekten. Es ist für Menschen vergleichsweise gut lesbar und lässt sich von nahezu jeder modernen Programmiersprache verarbeiten.

Ein einfaches JSON-Objekt sieht so aus:

{
  "kunde": "Muster GmbH",
  "anfrage": "Lieferstatus für Bestellung 4711",
  "sprache": "de",
  "prioritaet": "normal"
}

Beim JSON Prompt Engineering wird diese Struktur genutzt, um Informationen eindeutig voneinander zu trennen. Das Modell erkennt, welches Feld die Aufgabe beschreibt, welche Inhalte verarbeitet werden sollen und welche Regeln gelten. Diese Ordnung kann besonders bei langen oder wiederkehrenden Aufgaben helfen.

Wichtig ist die technische Einordnung: Ein Prompt muss nicht in JSON geschrieben sein, damit ein Modell präzise antwortet. Gut formulierte natürliche Sprache funktioniert häufig genauso gut oder besser. JSON ist sinnvoll, wenn Daten bereits strukturiert vorliegen, Felder dynamisch befüllt werden oder die Antwort in einem System weiterverarbeitet werden soll.

Drei Formen strukturierter KI-Kommunikation

Der Begriff „JSON Prompt“ wird für verschiedene Verfahren verwendet. Für eine zuverlässige Umsetzung solltest du unterscheiden, auf welcher Ebene die Struktur entsteht.

OpenAI, Google Gemini und Anthropic Claude unterstützen inzwischen strukturierte Ausgaben auf Basis von JSON Schema. Die konkrete Syntax und der unterstützte Schema-Umfang unterscheiden sich. Große, tief verschachtelte oder seltene Schema-Funktionen können abgelehnt oder ignoriert werden. Prüfe deshalb vor der Implementierung immer die aktuelle Dokumentation des verwendeten Modells.

JSON, JSON Schema und Function Calling unterscheiden

JSON beschreibt konkrete Daten

JSON ist eine Instanz mit tatsächlichen Werten. Ein Support-Ticket kann beispielsweise Kategorie, Priorität und Bestellnummer enthalten. Das Format sagt allein noch nicht, welche Felder erlaubt oder verpflichtend sind.

JSON Schema beschreibt die erlaubte Struktur

JSON Schema definiert Datentypen, Pflichtfelder und mögliche Werte. Es kann festlegen, dass die Priorität nur „niedrig“, „normal“ oder „hoch“ sein darf und eine fehlende Bestellnummer als null zurückgegeben wird. Ein Validator kann anschließend prüfen, ob konkrete JSON-Daten zu diesem Schema passen.

Structured Outputs kontrollieren die finale Antwort

Structured Outputs werden eingesetzt, wenn die endgültige Modellantwort einem vorgegebenen Schema entsprechen soll. Das ist beispielsweise bei der Extraktion von Rechnungsdaten oder bei der Klassifizierung eingehender E-Mails sinnvoll.

Function Calling strukturiert eine geplante Aktion

Beim Function Calling entscheidet das Modell, ob eine definierte Funktion oder ein Tool aufgerufen werden soll. Das JSON Schema beschreibt dabei die Parameter des Tool-Aufrufs. Die Anwendung prüft die Parameter und führt die Funktion aus. Structured Outputs formatieren hingegen meist das Endergebnis für deine Anwendung oder Benutzeroberfläche.

Die Trennung ist wichtig: Eine strukturierte Modellantwort sollte nicht automatisch eine Bestellung ändern, eine E-Mail versenden oder einen Datensatz löschen. Aktionen benötigen Berechtigungen, Validierung und bei relevanten Auswirkungen eine menschliche Freigabe.

Wann JSON Prompts sinnvoll sind

JSON entfaltet seinen Nutzen, wenn Informationen wiederholt in derselben Form verarbeitet werden. Typische Anwendungen sind:

• Datenextraktion: Rechnungsnummern, Beträge, Fristen oder Vertragsparteien aus Dokumenten erfassen.
• Klassifizierung: E-Mails, Tickets, Leads oder Feedback einer begrenzten Kategorie zuordnen.
• Content-Briefings: Zielgruppe, Suchintention, Kernaussagen und Formate für nachgelagerte Prozesse bereitstellen.
• Meeting-Auswertung: Beschlüsse, Aufgaben, Verantwortliche und Termine getrennt ausgeben.
• AI Agents: Informationen sicher zwischen spezialisierten Agenten, Tools und Unternehmenssystemen übergeben.
• Benutzeroberflächen: Modellantworten in Karten, Tabellen, Formularen oder Dashboards darstellen.

Für kreative Texte, Beratungsgespräche oder offene Ideenfindung kann eine starre JSON-Struktur unnötig einschränken. Ein kurzer, gut gegliederter Textprompt ist dann häufig angenehmer. Das Ausgabeformat sollte sich am nächsten Prozessschritt orientieren.

Wenn du JSON speziell zur Steuerung von Bildideen verwenden möchtest, findest du die getrennte Suchintention im Beitrag bessere KI-Bilder mit JSON Prompts.

Aufbau eines guten JSON Prompts

Eine praxistaugliche Eingabestruktur besteht aus wenigen klar benannten Bereichen. Sie sollte keine Felder enthalten, die im konkreten Prozess keine Funktion erfüllen.

{
  "task": "support_ticket_klassifizieren",
  "goal": "Ticket für die richtige Bearbeitungsgruppe vorbereiten",
  "input_data": {
    "subject": "Lieferung unvollständig",
    "message": "Bei Bestellung 4711 fehlt ein Artikel."
  },
  "rules": {
    "language": "de",
    "allowed_categories": [
      "lieferung",
      "rechnung",
      "produktfrage",
      "sonstiges"
    ],
    "missing_information": "null"
  },
  "output_requirements": {
    "format": "json",
    "include_short_summary": true
  }
}

Die wichtigsten Bausteine sind:

1. Task: Ein stabiler, maschinenlesbarer Name für die Aufgabe.
2. Goal: Eine kurze Erklärung des erwarteten Ergebnisses.
3. Input Data: Die konkreten Inhalte, die verarbeitet werden.
4. Rules: Kategorien, Sprache, Grenzwerte und Umgang mit fehlenden Angaben.
5. Output Requirements: Gewünschtes Format und notwendige Bestandteile.

Diese Struktur trennt Anweisung und Nutzdaten sichtbar voneinander. Bei untrusted Inhalten wie E-Mails, Webseiten oder hochgeladenen Dokumenten solltest du zusätzlich ausdrücklich festlegen, dass Text innerhalb von input_data als zu analysierende Information und nicht als neue Anweisung behandelt wird.

Ein belastbares JSON Schema erstellen

Für produktive Structured Outputs wird die Ausgabe nicht nur als Beispiel gezeigt, sondern als Schema definiert. Das folgende Schema beschreibt das erwartete Ergebnis der Ticket-Klassifizierung:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "category": {
      "type": "string",
      "enum": [
        "lieferung",
        "rechnung",
        "produktfrage",
        "sonstiges"
      ],
      "description": "Zuständige fachliche Kategorie"
    },
    "priority": {
      "type": "string",
      "enum": ["niedrig", "normal", "hoch"],
      "description": "Dringlichkeit nach den definierten Serviceregeln"
    },
    "summary": {
      "type": "string",
      "description": "Kurze sachliche Zusammenfassung auf Deutsch"
    },
    "order_id": {
      "type": ["string", "null"],
      "description": "Genannte Bestellnummer oder null"
    },
    "needs_human_review": {
      "type": "boolean",
      "description": "True bei unklaren oder risikoreichen Fällen"
    }
  },
  "required": [
    "category",
    "priority",
    "summary",
    "order_id",
    "needs_human_review"
  ],
  "additionalProperties": false
}

Ein mögliches Ergebnis lautet:

{
  "category": "lieferung",
  "priority": "normal",
  "summary": "In Bestellung 4711 fehlt ein Artikel.",
  "order_id": "4711",
  "needs_human_review": false
}

Die Angabe additionalProperties: false verhindert zusätzliche, nicht definierte Felder. Enumerationen begrenzen Kategorien auf bekannte Werte. Ein kombinierter Typ aus string und null schafft einen eindeutigen Umgang mit fehlenden Informationen.

Das Beispiel verwendet JSON Schema 2020-12 als allgemeinen Standard. Modellanbieter unterstützen häufig nur einen Teil der Spezifikation. Für eine API-Integration musst du das Schema an den dokumentierten Umfang des jeweiligen Providers anpassen. Der Schlüssel $schema kann je nach API entfallen.

Sieben Regeln für zuverlässige Schemata

1. Verwende stabile und eindeutige Feldnamen

Ein Feld sollte im gesamten System dieselbe Bedeutung behalten. Wechsle nicht zwischen customer_id, client_number und kunde, wenn überall dieselbe Kennung gemeint ist. Einheitliche Namen erleichtern Mapping, Logging und spätere Änderungen.

2. Nutze konkrete Datentypen

Eine Anzahl ist ein integer, ein Status ist ein begrenzter string und eine Ja-Nein-Entscheidung ist ein boolean. Die pauschale Verwendung von Textfeldern verschiebt Fehler in spätere Prozessschritte.

3. Begrenze Kategorien mit enum

Wenn eine Anwendung nur vier Kategorien kennt, sollte das Modell keine fünfte erfinden können. Definierte Werte verbessern Auswertung und Routing. Ergänze eine Kategorie wie „sonstiges“ und ein Review-Feld für Fälle außerhalb der Taxonomie.

4. Behandle fehlende Informationen explizit

Das Modell sollte fehlende Werte nicht erraten. Verwende null, ein separates Feld wie information_missing oder einen Review-Status. Leere Strings sind schwerer auszuwerten und können mit tatsächlich vorhandenen, aber kurzen Angaben verwechselt werden.

5. Beschreibe die fachliche Bedeutung

Das Feld description erklärt dem Modell und späteren Entwicklern, was erwartet wird. „Priorität“ reicht oft nicht. Besser ist eine Definition, die auf konkrete Serviceregeln oder Grenzwerte verweist.

6. Halte das Schema möglichst flach

Jede zusätzliche Verschachtelung erhöht Komplexität, Tokenverbrauch und Fehleranfälligkeit. Teile sehr große Ausgaben in mehrere fachliche Schritte, wenn die Felder unabhängig voneinander erzeugt oder geprüft werden können.

7. Versioniere produktive Schemata

Änderungen an Feldnamen oder Datentypen können nachgelagerte Systeme beschädigen. Ergänze eine Schema-Version, dokumentiere Migrationen und teste neue Versionen mit realistischen Beispielen, bevor sie produktiv eingesetzt werden.

Fünf JSON-Prompt-Beispiele für Unternehmen

1. Kundenanfragen klassifizieren

Ziel: Eingehende Nachrichten einer Bearbeitungsgruppe zuordnen und unklare Fälle markieren.

{
  "task": "classify_customer_message",
  "instruction": "Ordne die Nachricht genau einer erlaubten Kategorie zu. Erfinde keine fehlenden Informationen.",
  "allowed_categories": [
    "vertrieb",
    "support",
    "rechnung",
    "beschwerde",
    "sonstiges"
  ],
  "input_data": {
    "subject": "Doppelte Abbuchung",
    "message": "Der Betrag wurde in diesem Monat zweimal belastet."
  },
  "required_output": [
    "category",
    "priority",
    "summary",
    "needs_human_review"
  ]
}

Ein Schema mit enum verhindert freie Kategorien. Die Priorität sollte anhand dokumentierter Regeln bestimmt werden. Beschwerden, rechtliche Drohungen oder unklare Identitäten können automatisch zur manuellen Prüfung gehen.

2. Rechnungsdaten aus Dokumenten extrahieren

Ziel: Rechnungsnummer, Datum, Lieferant, Netto-, Steuer- und Bruttobetrag für eine Vorprüfung erfassen.

{
  "task": "extract_invoice_data",
  "instruction": "Extrahiere nur Angaben, die im Dokument eindeutig vorhanden sind. Verwende null für fehlende Werte.",
  "input_data": {
    "document_text": "[OCR- oder PDF-Text]"
  },
  "validation_rules": {
    "currency": ["EUR", "CHF", "USD"],
    "date_format": "YYYY-MM-DD",
    "human_review_if_totals_do_not_match": true
  }
}

Schema-Konformität bestätigt lediglich, dass beispielsweise gross_amount eine Zahl ist. Ob der Wert richtig gelesen wurde und ob Netto plus Steuer tatsächlich Brutto ergibt, muss durch deterministische Regeln kontrolliert werden.

3. Meeting-Protokolle in Aufgaben umwandeln

Ziel: Beschlüsse und Aufgaben mit Verantwortlichen und Terminen erfassen.

{
  "task": "extract_meeting_actions",
  "instruction": "Trenne bestätigte Beschlüsse von Vorschlägen. Weise keine Person zu, wenn die Verantwortung nicht eindeutig genannt wurde.",
  "input_data": {
    "meeting_notes": "[Transkript oder Notizen]"
  },
  "output_rules": {
    "unknown_owner": null,
    "unknown_due_date": null,
    "include_source_quote": true
  }
}

Ein kurzes Feld mit der relevanten Textstelle erleichtert die Kontrolle. Der Originaltext bleibt dabei die Quelle; die strukturierte Ausgabe ist eine abgeleitete Arbeitshilfe.

4. Leads nach transparenten Kriterien vorqualifizieren

Ziel: Anfragen anhand bekannter Kriterien vorbereiten, ohne automatisch über Menschen oder Unternehmen zu entscheiden.

{
  "task": "prepare_lead_review",
  "instruction": "Bewerte ausschließlich die angegebenen geschäftlichen Kriterien. Nutze keine sensiblen oder abgeleiteten personenbezogenen Merkmale.",
  "criteria": {
    "company_size": "provided_value",
    "stated_need": "required",
    "implementation_timeframe": "provided_value",
    "budget_information": "optional"
  },
  "input_data": {
    "lead_form": "[Formulardaten]"
  }
}

Die Ausgabe kann fehlende Angaben, passende nächste Fragen und eine nachvollziehbare Zusammenfassung enthalten. Eine automatische Ablehnung sollte bei relevanten geschäftlichen Entscheidungen vermieden oder klar kontrolliert werden.

5. Ein Content-Briefing für nachgelagerte Prozesse erstellen

Ziel: Rechercheergebnisse in ein stabiles Briefing für Redaktion, Design und Veröffentlichung überführen.

{
  "task": "create_content_brief",
  "instruction": "Erstelle ein sachliches Briefing. Trenne belegte Fakten, redaktionelle Empfehlungen und offene Fragen.",
  "input_data": {
    "topic": "[Thema]",
    "target_audience": "[Zielgruppe]",
    "search_intent": "[Suchintention]",
    "verified_sources": [
      "[Quelle 1]",
      "[Quelle 2]"
    ]
  },
  "required_output": [
    "core_question",
    "key_messages",
    "outline",
    "verified_facts",
    "open_questions",
    "recommended_internal_links"
  ]
}

Für mehrstufige Content-Prozesse kann dieses Briefing an weitere Agenten übergeben werden. Wie solche Schritte verbunden werden, erkläre ich auch im Beitrag über Prompt Chaining.

Structured Outputs bei OpenAI, Gemini und Claude

Die großen Modellplattformen verfolgen ein ähnliches Grundprinzip: Du übergibst neben der Aufgabe ein Schema, und die Generierung wird auf eine passende Struktur beschränkt. Die Details unterscheiden sich jedoch.

Wähle deshalb zuerst den geschäftlichen Vertrag für deine Daten und übersetze ihn anschließend in die API-Syntax des Providers. Wenn du ein Modell wechselst, testest du Schema-Unterstützung, optionale Felder, Refusals, Abbrüche und Fehlermeldungen erneut.

Strukturtreue ersetzt keine fachliche Validierung

Structured Outputs können garantieren, dass ein Feld vorhanden ist und den erwarteten Datentyp besitzt. Sie können nicht garantieren, dass der enthaltene Wert stimmt. Ein Modell kann eine syntaktisch korrekte, aber sachlich falsche Rechnungsnummer zurückgeben.

Ein belastbarer Workflow prüft deshalb mehrere Ebenen:

1. Transport: War die Anfrage technisch erfolgreich und vollständig?
2. Syntax: Ist die Antwort gültiges JSON?
3. Schema: Entsprechen Felder, Typen und erlaubte Werte der Spezifikation?
4. Geschäftslogik: Stimmen Summen, Datumsbereiche, IDs und fachliche Regeln?
5. Quelle: Lassen sich extrahierte Angaben im Originaldokument belegen?
6. Berechtigung: Darf der nächste Prozessschritt mit diesen Daten ausgeführt werden?
7. Review: Benötigt der Fall aufgrund von Unsicherheit oder Auswirkungen eine menschliche Entscheidung?

Diese Prüfungen sollten außerhalb des Sprachmodells mit normalem Anwendungscode, Datenbankabfragen und klaren Freigaberegeln umgesetzt werden. Das Modell darf Unsicherheit signalisieren, sollte aber nicht seine eigene einzige Kontrollinstanz sein.

Häufige Fehler beim JSON Prompt Engineering

• JSON wird mit JSON Schema verwechselt: Ein Beispielobjekt beschreibt mögliche Daten, aber noch keine verbindlichen Typen und Regeln.
• Nur der Prompt fordert „gültiges JSON“: Im Chat bleibt dies eine Anweisung. Produktive Anwendungen nutzen den strukturierten Ausgabemodus der API.
• Zu viele optionale Felder: Unklare Leerwerte erschweren nachgelagerte Logik. Definiere explizit, wann null verwendet wird.
• Freie Kategorien: Ohne enum entstehen Schreibvarianten und neue Begriffe, die das Routing stören.
• Überladene Schemata: Tiefe Verschachtelungen und hunderte Felder erhöhen Latenz und Implementierungsaufwand.
• Keine fachliche Prüfung: Schema-konforme Werte können sachlich falsch sein.
• Ungeprüfte Tool-Aufrufe: Gültige Parameter sind noch keine Freigabe für eine externe Aktion.
• Keine Versionierung: Eine kleine Feldänderung kann mehrere abhängige Systeme beschädigen.
• Keine realistischen Tests: Ein einzelnes Beispiel bildet fehlende Daten, Widersprüche und Grenzfälle nicht ab.

JSON Prompts sicher in AI Agents einsetzen

AI Agents verwenden strukturierte Daten häufig als Übergabe zwischen Analyse, Tool-Auswahl und Aktion. Dadurch wird der Prozess nachvollziehbarer, aber nicht automatisch sicher. Inhalte aus E-Mails, Websites, Dokumenten oder Tool-Antworten können manipulierte Anweisungen enthalten.

OWASP empfiehlt deshalb mehrere Schutzebenen: Eingaben und Ausgaben validieren, Anweisungen klar von untrusted Daten trennen, Tools nach dem Prinzip der geringsten Berechtigung freigeben und relevante Aktionen durch Menschen bestätigen lassen. Für Agenten-Workflows kommen Allow Lists, Limits, Protokollierung und definierte Abbruchbedingungen hinzu.

• Behandle externe Inhalte als Daten, nicht als vertrauenswürdige Anweisung.
• Erlaube nur bekannte Tool-Namen und geprüfte Parameter.
• Validiere IDs, Beträge und Empfänger gegen das Zielsystem.
• Fordere vor irreversiblen oder extern sichtbaren Aktionen eine Freigabe an.
• Speichere Schema-Version, Modellversion, Prompt-Version und Prüfergebnis im Protokoll.
• Definiere einen sicheren Zustand für Fehler und unvollständige Antworten.

So entwickelst du JSON Prompts systematisch

1. Beginne mit dem nachgelagerten Prozess

Welche Felder benötigt das CRM, die Datenbank oder die Benutzeroberfläche tatsächlich? Übernimm nur diese Felder in das Schema. Jede zusätzliche Information verursacht Aufwand bei Generierung, Prüfung und Datenschutz.

2. Erstelle repräsentative Testfälle

Nutze einfache, mehrdeutige, unvollständige und widersprüchliche Beispiele. Ergänze Sonderfälle mit sehr langen Texten, mehreren Sprachen und ungültigen IDs. Für jede Eingabe definierst du das erwartete Ergebnis oder zumindest klare Akzeptanzkriterien.

3. Messe mehr als gültiges JSON

Eine Parse-Rate von 100 Prozent ist bei Structured Outputs erreichbar, sagt aber wenig über fachliche Qualität. Messe Feldgenauigkeit, Vollständigkeit, Review-Quote, falsche Freigaben, Latenz und Kosten pro erfolgreich verarbeitetem Vorgang.

4. Trenne Prompt, Schema und Geschäftsregeln

Der Prompt beschreibt die Aufgabe, das Schema den Datenvertrag und Anwendungscode die überprüfbaren Regeln. Diese Trennung erleichtert Änderungen und verhindert, dass kritische Logik nur in einem langen Prompt versteckt bleibt.

5. Beobachte Änderungen im Betrieb

Modellwechsel, neue Dokumenttypen und veränderte Kundensprache können die Qualität beeinflussen. Stichproben, Monitoring und wiederkehrende Evals zeigen, ob das System weiterhin innerhalb der vereinbarten Grenzen arbeitet.

Vom JSON Prompt zum unternehmensweiten KI-System

In einem einzelnen Chat ist JSON eine nützliche Ordnungshilfe. Im Unternehmen wird daraus ein verbindlicher Übergabepunkt zwischen Menschen, AI Agents und bestehenden Anwendungen. Dafür braucht es mehr als eine Prompt-Sammlung: freigegebene Datenquellen, Rollen, Berechtigungen, Versionen, Qualitätskontrollen und klare Verantwortlichkeiten.

Mit AI Cowork entwickeln wir solche Arbeitsumgebungen für Unternehmen. Fachwissen, Prozesse und spezialisierte AI Agents werden so organisiert, dass strukturierte Ergebnisse direkt in kontrollierte Abläufe einfließen können. Ein Meeting Agent kann beispielsweise Aufgaben als geprüftes JSON übergeben, während ein CRM-Agent nur jene Felder verarbeitet, für die er eine definierte Berechtigung besitzt.

Die technische Struktur bleibt dabei Mittel zum Zweck. Entscheidend sind verlässliche Übergaben, nachvollziehbare Entscheidungen und ein System, das sich an reale Unternehmensprozesse anpasst.

Fazit: Struktur schafft eine belastbare Schnittstelle

JSON Prompt Engineering ist besonders wertvoll, wenn KI-Ergebnisse von Software weiterverarbeitet werden. Ein strukturierter Prompt ordnet Aufgabe und Eingabedaten. JSON Schema definiert den erwarteten Datenvertrag. Structured Outputs erhöhen die Schema-Treue. Deterministische Validierung und menschliche Freigaben sichern die fachliche Anwendung ab.

Starte mit einem kleinen, klar abgegrenzten Prozess. Definiere wenige Felder, teste reale Grenzfälle und messe fachliche Qualität. Wenn der Ablauf stabil ist, kannst du weitere Systeme und Agenten über versionierte Schemata anbinden.

Wenn du strukturierte KI-Ausgaben in CRM, E-Mail, Meetings oder interne Wissensprozesse integrieren möchtest, kannst du dir AI Cowork für Unternehmen ansehen. Gemeinsam klären wir, welche Datenverträge, Prüfungen und Freigaben dein konkreter Anwendungsfall benötigt.

Häufige Fragen zu JSON Prompt Engineering

Offizielle Quellen und weiterführende Dokumentation

• OpenAI: Responses API und strukturierte Ausgabeformate
• Google AI for Developers: Structured Outputs mit Gemini
• Anthropic: Structured Outputs mit Claude
• Anthropic: Striktes Tool Use mit JSON Schema
• JSON Schema: Grundlagen und aktuelle Spezifikation
• OWASP: Schutz vor Prompt Injection in LLM-Anwendungen

Über den Autor

Peter Krause

KI-Berater, Buchautor & Gründer

Über Peter Krause LinkedIn KI-Buch