KI & Automatisierung

Strukturierte Ausgaben für AI-Automatisierung - Ein Schema ist ein Vertrag, keine Sicherheitsprüfung

Geschrieben von Adam Muiz 10 Sep 2026 Aktualisiert: 10 Sep 2026 10 Min. gelesen

Ein Sprachmodell kann sauberes JSON statt eines Absatzes zurückgeben. Das wirkt wie ein entscheidender Schritt hin zu zuverlässiger Automatisierung: Die Schlüssel sind vorhanden, die Typen sehen richtig aus, und der Parser muss keinen unvollständigen Codeblock mehr retten. Doch was genau ist dadurch zuverlässiger geworden?

Eine strukturierte Antwort kann es Software erleichtern, mit einem nicht immer zuverlässigen Modell zu kommunizieren. Sie macht jedoch nicht jeden Wert wahr, jede angeforderte Aktion angemessen oder jede Nebenwirkung sicher. Die nützliche Frage lautet deshalb nicht: „Hat das Modell gültiges JSON zurückgegeben?“, sondern: „Welche Prüfstellen muss diese Anfrage passieren, bevor die Anwendung handeln darf?“

Diese Unterscheidung ist besonders wichtig, wenn eine Ausgabe nicht mehr nur Text ist, sondern Autorität erhält: einen Beitrag veröffentlichen, eine Nachricht senden, eine Datei ändern oder eine administrative API aufrufen. Ein konservatives Design lässt das Modell eine eng strukturierte Aktion vorschlagen, während deterministischer Anwendungscode entscheidet, ob dieser Vorschlag ausgeführt werden darf.

Fünf verschiedene Fragen hinter dem Wort „gültig“

Das Wort gültig ist mehrdeutig. Eine kleine Automatisierungspipeline sollte mindestens fünf Fragen voneinander trennen:

Lässt sich die Ausgabe parsen? Ist die Antwort gültiges JSON?
Entspricht sie dem Vertrag? Sind Pflichtfelder vorhanden, haben Werte den erwarteten Typ, und liegen Auswahlwerte innerhalb der deklarierten Grenzen?
Ist sie im aktuellen Zustand sinnvoll? Existiert der referenzierte Entwurf, wird die Locale unterstützt, und ist der gewünschte Termin noch verfügbar?
Darf dieser Akteur die Aktion ausführen? Ist der Benutzer oder Dienst für diese Ressource und Operation autorisiert, und ist eine Freigabe erforderlich?
Lässt sie sich sicher ausführen? Würden Wiederholungen die Wirkung duplizieren, sind Ressourcen begrenzt, und hinterlässt ein Fehler einen verständlichen Zustand?

RFC 8259 definiert JSON als Datenaustauschformat mit einer kleinen Grammatik. Das Bestehen dieser Grammatik beantwortet nur die erste Frage. Es sagt nichts darüber aus, ob ein Slug einen realen Entwurf bezeichnet oder ob der Aufrufer ihn veröffentlichen darf.

Die JSON-Schema-Validierung kann einen Teil der zweiten Frage mit Assertions wie type, required, enum und Längenbeschränkungen beantworten. Das ist wertvoll. Ein Vertrag, der unerwartete Formen ablehnt, ist wesentlich besser als die Suche nach einem Token wie [PUBLISH] in Fließtext. Er ist dennoch nur eine Schicht und nicht die gesamte Entscheidung.

Ein Schema grenzt die Kommunikation ein

Angenommen, ein Assistent darf vorschlagen, was mit einem vorhandenen Artikelentwurf geschehen soll. Ein bewusst kleiner Vertrag könnte so aussehen:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "action": {
      "type": "string",
      "enum": ["request_review", "schedule"]
    },
    "draft_id": {
      "type": "integer",
      "minimum": 1
    },
    "locale": {
      "type": "string",
      "enum": ["en", "id", "de"]
    },
    "scheduled_at": {
      "type": ["string", "null"]
    },
    "reason": {
      "type": "string",
      "minLength": 1,
      "maxLength": 500
    }
  },
  "required": ["action", "draft_id", "locale", "scheduled_at", "reason"],
  "additionalProperties": false
}

Das Enum verhindert, dass das Modell eine Aktion wie delete_everything erfindet. Die Integer-Beschränkung weist eine negative Kennung zurück. Die Allowlist für Locales begrenzt die Schnittstelle auf Sprachen, die die Anwendung tatsächlich unterstützt. additionalProperties: false macht versehentliche oder erfundene Felder sichtbar, statt sie stillschweigend zu akzeptieren.

Aktuelle Modell-APIs zeigen zwei verwandte Muster. OpenAI dokumentiert durch ein Schema eingeschränkte Modellantworten, während Anthropic Tool-Definitionen mit einem input_schema dokumentiert. APIs und unterstützte Schemafunktionen können sich ändern. Eine Anwendung muss daher die Dokumentation des tatsächlich eingesetzten Providers und Modells beachten. „Strict“ sollte nicht als ein portables, in jeder Implementierung identisches Verhalten verstanden werden.

Die dauerhafte Idee ist providerneutral: Definiere den kleinsten maschinenlesbaren Vorschlag, den die Anwendung benötigt. Stelle keinen allgemeinen Shell-Befehl bereit, wenn die Aufgabe nur eine Auswahl zwischen Review und Terminplanung erfordert. Ein enges Vokabular reduziert Mehrdeutigkeit sowohl für das Modell als auch für den Executor.

Eine korrekte Form ist noch keine Wahrheit

Betrachten wir nun folgenden schemakonformen Vorschlag:

{
  "action": "schedule",
  "draft_id": 417,
  "locale": "de",
  "scheduled_at": "2026-09-10T00:00:00+07:00",
  "reason": "The translation is complete."
}

Seine Form kann perfekt sein, obwohl jede operative Schlussfolgerung falsch ist. Entwurf 417 existiert vielleicht nicht. In der deutschen Übersetzung könnte noch ein Absatz fehlen. Der Zeitstempel könnte bei der Verarbeitung bereits in der Vergangenheit liegen. Ein anderer Artikel könnte den täglichen Slot belegen. Der Aufrufer könnte nur die Berechtigung für ein Review besitzen. Der Satz in reason bleibt generierter Text und ist kein Beleg.

Diese Grenze ergibt sich aus der Aufgabe von Schemas. Die JSON-Schema-Kernspezifikation besagt, dass eine Instanz nur an einer Assertion scheitern kann, die im Schema vorhanden ist. Ein Schema kann keine nicht formulierte Regel ablehnen. Selbst deklarierte Stringformate haben Feinheiten: Die Validierungsspezifikation erklärt, dass format je nach Vokabular und Implementierung lediglich eine Annotation sein kann und dass eine syntaktische Prüfung nicht belegt, ob eine bezeichnete Entität existiert.

Der Anwendungscode benötigt deshalb nach der Schemavalidierung eine Phase für semantische Prüfungen. In diesem Beispiel könnte sie den Entwurf anhand seiner ID laden, seine tatsächliche Locale und seinen Status vergleichen, den Veröffentlichungskalender prüfen und bestätigen, dass erforderliche Übersetzungen und Medien vorhanden sind. Das sind gewöhnliche Abfragen gegen einen maßgeblichen Zustand. Das Modell durch eine weitere generierte Antwort zum „erneuten Prüfen“ aufzufordern, ist nicht gleichwertig.

Den Vorschlag als nicht vertrauenswürdige Eingabe behandeln

Eine Modellantwort kann durch Benutzerprompts, abgerufene Dokumente, Tool-Ergebnisse oder frühere Modellausgaben beeinflusst werden. Eine Anwendung sollte nicht annehmen, dass eine strukturierte Herkunft zugleich eine vertrauenswürdige Herkunft ist. Die OWASP-Leitlinie zu Improper Output Handling empfiehlt, Modellausgaben wie nicht vertrauenswürdige Eingaben zu behandeln und zu validieren, bevor sie nachgelagerte Funktionen erreichen.

Aus diesem Prinzip folgen bekannte Engineering-Regeln:

Kennungen werden durch Anwendungscode aufgelöst; generierte Strings werden nicht in SQL-Fragmente umgewandelt.
Ein erlaubter Aktionsname wird einer bestimmten Funktion zugeordnet; Modelltext wird weder an eine Shell noch an eval() übergeben.
Generierter Text wird für seinen Zielkontext codiert; schemagültiger Text in HTML-Form ist nicht automatisch sicheres HTML.
Unbekannte Felder und Werte werden abgelehnt, statt die Absicht des Modells zu erraten.
Validierungsfehler werden als Daten zurückgegeben und nicht als Erlaubnis, einen mächtigeren Fallback zu versuchen.

Das ist kein Argument gegen strukturierte Ausgaben. Es erklärt, warum sie nützlich sind: Ein enges Objekt lässt sich leichter validieren und sicher weiterleiten als freie Prosa. Der Fehler besteht darin, den Datenvertrag zugleich als Sicherheitsgrenze zu behandeln, für die er nie entworfen wurde.

Autorisierung muss außerhalb des Modells stattfinden

Ein Prompt kann einem Modell mitteilen, welche Aktionen erlaubt sind, doch ein Prompt ist kein Zugriffskontrollsystem. Der Executor muss den tatsächlichen Aufrufer authentifizieren und die Richtlinie anhand serverseitigen Zustands durchsetzen. Darf ein Benutzer nur eigene Entwürfe bearbeiten, müssen Datenbankabfrage oder Service-Schicht diese Eigentumsgrenze unabhängig von der durch das Modell vorgeschlagenen ID bewahren.

Die OWASP-Leitlinie zu Excessive Agency unterscheidet drei hilfreiche Reduktionen: verfügbare Funktionalität, nachgelagerte Berechtigungen und Autonomie minimieren. Eine Nur-Lese-Abfrage sollte eine Nur-Lese-Identität verwenden. Ein Tool, das einen genehmigten Entwurf terminiert, sollte nicht zugleich beliebige Update- oder Löschoperationen bereitstellen. Aktionen mit hoher Auswirkung können in einem Review-Status anhalten, bis eine Person das genaue Ziel und die Wirkung freigibt.

Menschliche Freigabe ist nicht automatisch hilfreich. Eine vage Schaltfläche zur „Freigabe einer AI-Ausgabe“ fördert reflexartiges Klicken. Ein sinnvoller Kontrollpunkt zeigt die vorgeschlagene Aktion, das Ziel, wichtige Änderungen, die Autoritätsquelle und die Konsequenz. Die Freigabe sollte außerdem verfallen, wenn sich der zugrunde liegende Entwurf ändert. Andernfalls könnte eine Person eine Version freigeben, während das System eine andere ausführt.

Vorschlag, Entscheidung und Wirkung trennen

Ein sauberer Workflow führt nicht direkt von der Modellantwort zur Nebenwirkung. Er zeichnet unterschiedliche Zustände auf:

model response
  -> parsed proposal
  -> schema accepted
  -> policy decision
  -> awaiting approval (when required)
  -> execution attempt
  -> succeeded or failed

Diese Trennung macht Fehler weniger rätselhaft. Eine Schemaablehnung bedeutet, dass der Vertrag nicht erfüllt wurde. Eine Richtlinienablehnung bedeutet, dass die Anfrage korrekt geformt, aber nicht erlaubt war. Ein Ausführungsfehler bedeutet, dass bei einer genehmigten Operation ein betriebliches Problem auftrat. Alle drei als „die AI ist gescheitert“ zusammenzufassen, verbirgt den Teil des Systems, der repariert werden muss.

Der Entscheidungsdatensatz sollte stabile Kennungen und die Version des geprüften Objekts referenzieren. Bei folgenreichen Schreibvorgängen kann ein Idempotency Key oder eine gleichwertige Eindeutigkeitsregel verhindern, dass eine Wiederholung denselben logischen Effekt erneut auslöst. Das ist wichtig, weil Timeouts mehrdeutig sind: Ein Client kann die Antwort verlieren, nachdem der Server die Aktion bereits abgeschlossen hat.

Auch Wiederholungen sollten begrenzt sein. Fehlerhafte oder verbotene Vorschläge erneut zu versuchen, verschwendet Ressourcen und kann einen Angriff verschleiern. Die Wiederholung eines vorübergehenden Netzwerkfehlers kann sinnvoll sein, aber nur, wenn die Operation wiederholungssicher ist und das System zwischen „nicht versucht“ und „abgeschlossen, aber Antwort verloren“ unterscheiden kann.

Logs sollten Entscheidungen erklären, ohne ein neues Leck zu werden

Ein Audit-Trail sollte praktische Fragen beantworten: Welcher authentifizierte Akteur initiierte die Anfrage, welche Modellkonfiguration erzeugte den Vorschlag, welche Schemaversion wurde angewendet, welche Regeln bestanden oder scheiterten, wer gab ihn frei, welches Tool lief, und welcher Endzustand entstand?

Dafür müssen nicht alle Prompts und Antworten unbegrenzt gespeichert werden. Rohkontext kann personenbezogene Daten, Zugangsdaten, private Dokumente oder schädliche Anweisungen enthalten. Strukturierte Ereignisfelder, redigierte Geheimnisse, begrenzte Aufbewahrung und eingeschränkter Zugriff sind vorzuziehen. Gespeichert werden sollte genug, um eine Entscheidung zu rekonstruieren, nicht eine unbegrenzte Kopie von allem, was das Modell gesehen hat.

Auch Versionierung ist hier wichtig. Wenn sich ein Schema oder eine Richtlinie ändert, muss eine spätere Prüfung erkennen können, welche Regeln den alten Vorschlag bewertet haben. Die umfassendere Lehre entspricht der Lifecycle-Perspektive von NIST AI 600-1: Risikomanagement gehört in Design, Entwicklung, Nutzung und Evaluation. Es lässt sich nicht auf eine einzelne API-Option bei der Generierung reduzieren.

Eine kurze Prüfliste

Wird die Antwort mit einem JSON-Parser statt durch ausführbare Auswertung geparst?
Validiert die Anwendung gegen genau das Schema und den Dialekt, die sie unterstützen will?
Sind Aktionen, Kennungen, Größen und Sammlungen eng begrenzt?
Prüft deterministischer Code nach der Schemavalidierung den aktuellen Geschäftszustand?
Erzwingt der nachgelagerte Dienst Authentifizierung, Eigentumsgrenzen und minimale Rechte?
Erfordern folgenreiche Aktionen eine konkrete, nachvollziehbare Freigabe?
Kann ein Timeout oder eine Wiederholung die Nebenwirkung duplizieren?
Sind Fehlerzustände getrennt und Logs nützlich, ohne unnötig Geheimnisse aufzubewahren?
Werden Änderungen an Schema, Richtlinie und Tools sowohl mit ungültigen als auch gültigen Vorschlägen getestet?

Ein Vertrag, kein Urteil

Strukturierte Ausgabe löst ein reales Integrationsproblem. Sie ersetzt zerbrechliches Parsen von Prosa durch einen expliziten Vertrag und kann Modellantworten auf eine deutlich kleinere Menge von Formen beschränken. Das ist eine bedeutende Verbesserung.

Die Grenze ist ebenso wichtig: Ein Schema kann feststellen, dass ein Vorschlag wie schedule draft 417 aussieht. Es kann allein nicht feststellen, ob Entwurf 417 existiert, vollständig ist, dem Aufrufer gehört, unverändert ist, zur heutigen redaktionellen Richtlinie passt oder jetzt veröffentlicht werden sollte.

Zuverlässige Automatisierung entsteht aus der Verbindung bescheidener Garantien. Die Daten parsen. Ihre deklarierte Form validieren. Realität und Richtlinie mit deterministischem Code prüfen. Autorität nachgelagert durchsetzen. Eine Freigabe verlangen, wenn die Konsequenzen diese Reibung rechtfertigen. Danach begrenzt und wiederholungssicher ausführen. Das Modell darf den nächsten Schritt vorschlagen, doch die Anwendung muss dafür verantwortlich bleiben, ob dieser Schritt erlaubt ist.