OpenAIs Decisions API zielt auf die kleinen Entscheidungen, die KI-Workflows ausbremsen

OpenAIs neue Decisions API zielt auf einen Bereich von KI-Software, der in Produktvorführungen selten auftaucht: die kleine Entscheidung zwischen zwei größeren Schritten.

Soll diese Supportanfrage an die Abrechnung oder den technischen Support gehen? Ist ein Dokument vollständig genug, um in den nächsten Workflow zu gelangen? Sieht ein generierter Shell-Befehl sicher genug aus, um automatisch ausgeführt zu werden? Soll ein Sprachassistent eine Rückfrage stellen, das Gespräch weiterleiten oder fortfahren?

Diese Entscheidungen lassen sich leicht beschreiben, aber Fehler bei ihrer Ausführung sind teuer. Wenn eine Anwendung für jede eingehende Nachricht, jedes Dokument, jede Transaktion oder jedes Tool-Ergebnis eine solche Entscheidung trifft, summiert sich die Latenz. Auch die Kosten dafür, jede Frage durch ein Allzweckmodell zu schicken, wachsen schnell. Eine falsche Klassifizierung kann Arbeit in die falsche Warteschlange schicken, Informationen dem falschen Bearbeiter offenlegen oder eine Aktion auslösen, die eigentlich auf eine Prüfung hätte warten sollen.

OpenAI hat die Decisions API am 22. Oktober 2026 allgemein verfügbar gemacht. Sie läuft auf GPT-6 Luna und liefert typisierte Antworten statt eines Absatzes: eine Wahrscheinlichkeit, eine Auswahl aus einer vorgegebenen Menge oder eine Bewertung anhand eines geordneten Rasters. Nach Angaben von OpenAI ist der Endpunkt dafür ausgelegt, solche begrenzten Fragen bis zu zehnmal schneller zu beantworten als GPT-6 Luna über die Responses API. Das Unternehmen nennt einen Preis von 0,10 US-Dollar pro einer Million Eingabetoken; für den Endpunkt fallen keine Gebühren für Ausgabetoken an.

Diese Kombination macht Decisions für Teams interessant, die bereits KI-Produkte entwickeln. Als Ersatz für einen allgemeinen Assistenten ist die API weniger spannend. Die entscheidende Frage lautet nicht, ob das Modell schlussfolgern kann. Es geht darum, ob ein Team eine hinreichend enge Entscheidung definieren kann, um sie zu messen, mit einem sinnvollen Schwellenwert zu versehen und die daraus entstehende Aktion in einem kontrollierten Workflow zu halten.

Was die API tatsächlich zurückgibt

Der Endpunkt akzeptiert gemeinsame Belege und eine oder mehrere Fragen. Die Belege können aus Text, einer geordneten Unterhaltung mit Tool-Aufrufen und deren Ausgaben, Bildern oder strukturiertem JSON bestehen. Jede Frage hat einen Typ, einen Namen, Anweisungen und, sofern relevant, eine Menge zulässiger Auswahlmöglichkeiten oder geordneter Bewertungsstufen.

Ein predicate schätzt, ob eine Bedingung wahr ist, und gibt eine Wahrscheinlichkeit zwischen null und eins zurück. Das passt zu Fragen wie „Beschreibt dieses Ticket eine doppelte Abbuchung, die durch den Bestelldatensatz belegt ist?“ oder „Zeigt dieses Bild sichtbare Schäden?“

Eine choice wählt einen Wert aus einer vorgegebenen Menge. Ein Weiterleitungssystem könnte billing, technical_support, account_access und human_review anbieten. Eine Sprachanwendung könnte zwischen continue, clarify, transfer und end_call wählen.

Ein score bewertet eine Eingabe anhand geordneter Stufen, etwa niedriger, mittlerer und hoher Dringlichkeit. Die Antwort enthält Wahrscheinlichkeiten für die einzelnen Stufen sowie einen wahrscheinlichkeitsgewichteten Durchschnitt. Dieser Durchschnitt kann zwischen zwei Stufen liegen, was für eine Rangfolge nützlich ist, aber gefährlich wird, wenn ein Entwickler ihn als magisch präzise Messung behandelt.

Der Endpunkt kann bis zu 400 Fragen in einer Anfrage stellen – doppelt so viele wie das Limit von 200 Fragen während der öffentlichen Beta-Phase. Das ist relevant, wenn viele unabhängige Merkmale anhand derselben Belege bewertet werden können. Es bedeutet nicht, dass voneinander abhängige Entscheidungen gebündelt werden sollten. Wenn Frage zwei erst nach der Beantwortung von Frage eins gestellt werden sollte, machen getrennte Anfragen den Kontrollfluss leichter prüf- und testbar.

Die typisierte Ausgabe der API ist der wichtigste Produktunterschied. Ein allgemeines Modell kann zwar angewiesen werden, JSON zurückzugeben, doch ein Entwickler muss diese Ausgabe weiterhin validieren und fehlerhafte oder mehrdeutige Werte behandeln. Decisions begrenzt den Antwortbereich bereits auf API-Ebene. Das reduziert den Aufwand für das Parsen, macht die zugrunde liegende Einschätzung aber nicht automatisch korrekt.

Wo die API in eine echte Anwendung passt

Die überzeugendsten Anwendungsfälle sind wiederkehrende Entscheidungen mit einer begrenzten Menge an Antworten und einem klaren nächsten Schritt. Man kann sich den Endpunkt als schnelle Urteilsschicht innerhalb eines bestehenden Programms vorstellen, nicht als autonomen Mitarbeiter.

Ein Dokumenten-Workflow könnte damit entscheiden, ob ein hochgeladenes Zertifikat die erforderlichen Felder enthält, eine Dokumentenkategorie erkennen und das Element an die passende Warteschlange weiterleiten. Die eigentliche Dokumentenextraktion kann weiterhin ein separates System erfordern. Decisions beantwortet die engere Frage, was als Nächstes geschehen soll.

Ein Supportsystem könnte ein Ticket klassifizieren, seine Dringlichkeit einschätzen und feststellen, ob die Nachricht des Kunden genügend Informationen für eine erste Antwort enthält. Ein Ergebnis mit geringer Zuverlässigkeit könnte an eine menschliche Warteschlange gehen, statt zum Versand einer automatischen Antwort verwendet zu werden.

Ein Agenten-Orchestrierungssystem könnte eine Auswahlfrage nutzen, um das nächste Tool aus einer kleinen, geprüften Menge auszuwählen. Eine eingehende Anfrage könnte beispielsweise an ein Suchwerkzeug, eine Kontenabfrage, eine Terminplanungsfunktion oder einen Klärungsschritt weitergeleitet werden. Das Modell wählt zwischen diesen Optionen; die Anwendung bleibt für Berechtigungen, die Validierung von Argumenten, Ratenbegrenzungen und die Ausführung verantwortlich.

Ein Sicherheits- oder Operations-Workflow könnte eine geplante Aktion vor ihrer Ausführung bewerten. OpenAI nennt Datadog als Beispiel: Das Unternehmen nutzt den Endpunkt, um von Agenten erzeugte Shell-Befehle vor einer autonomen Behebung zu beurteilen. Dieses Muster kann nützlich sein, sollte aber nicht als vollständige Sicherheitsgrenze verstanden werden. Eine modellbasierte Bewertung kann ein zusätzliches Prüfsignal liefern. Sie ersetzt jedoch weder Befehls-Allowlists, Sandboxing, Identitätsprüfungen, Dateisystembeschränkungen noch eine Genehmigungsrichtlinie.

Auch Sprachanwendungen eignen sich dafür, weil eine langsame Entscheidung für die sprechende Person sofort bemerkbar ist. Decisions verfügt inzwischen über eine native GPT-Live-Integration und kann ausgelöst werden, sobald Eingabe- oder Ausgabetranskripte eintreffen. Eine Anwendung könnte entscheiden, ob der Assistent um eine Klarstellung bitten, einen Anruf weiterleiten oder den Status einer Interaktion aktualisieren soll. OpenAI zufolge verkürzte Speak in Tests mit dieser Integration die Zeit bis zur nächsten Aktion von 1,4 Sekunden auf 0,13 Sekunden. Das ist ein vom Anbieter gemeldetes Ergebnis und keine Garantie für jeden Voice-Stack. Es zeigt jedoch, warum ein spezialisierter Endpunkt in einer interaktiven Schleife wichtiger sein kann als in einem Batch-Prozess.

Die praktische Architektur: Modell, Schwellenwert, Aktion

Eine zuverlässige Implementierung braucht drei getrennte Ebenen.

Die erste Ebene ist die Frage. Sie sollte beobachtbare Hinweise beschreiben und benachbarte Antwortmöglichkeiten voneinander abgrenzen. „Ist das gut?“ ist keine Produktionsfrage. „Enthält die Nachricht eine Bitte, ein kostenpflichtiges Abonnement zu kündigen, statt eine Anfrage zu Preisen?“ kommt dem schon deutlich näher.

Die zweite Ebene ist die Richtlinie, die das Ergebnis interpretiert. Eine Wahrscheinlichkeit von 0,82 bedeutet nicht, dass die Anwendung handeln muss. Das Team muss festlegen, ob 0,82 für eine automatische Weiterleitung ausreicht, ob 0,55 eine Prüfung auslösen soll und ob bestimmte Kategorien unabhängig von der Konfidenz immer eine Person erfordern.

Die dritte Ebene ist die Aktion. Das Modell sollte nicht allein deshalb weitreichende Befugnisse erhalten, weil es eine gültige Auswahl zurückgegeben hat. Die Anwendung sollte einen zulässigen Wert einer bekannten Funktion zuordnen und alles außerhalb dieser Zuordnung ablehnen. Für sensible Vorgänge sollte eine unabhängige Autorisierung und gegebenenfalls eine Bestätigung durch einen Menschen erforderlich sein.

Diese Trennung macht auch eine Bewertung möglich. Teams können einen Schwellenwert ändern, ohne den Prompt neu zu schreiben. Sie können Modellentscheidungen mit gekennzeichneten Beispielen vergleichen. Außerdem können sie Fehlalarme und übersehene Fälle entsprechend den Kosten der jeweiligen Fehler messen. Ein Betrugsfilter, ein Support-Router und eine Warteschlange für die Inhaltsmoderation sollten nicht einfach denselben Schwellenwert verwenden, nur weil sie dieselbe API nutzen.

OpenAIs Entwicklerleitfaden weist auf etwas Ähnliches hin: Schwellenwerte sollten anhand gekennzeichneter Beispiele aus der jeweiligen Anwendung festgelegt werden. Dieser Rat wird leicht übersehen, weil der Endpunkt Wahrscheinlichkeiten und Konfidenzwerte zurückgibt, die quantitativ wirken. Diese Zahlen sind für Ranking und Routing nur dann nützlich, wenn sie mit den eigenen Daten der Organisation kalibriert wurden.

Prompt-Design ist jetzt Richtliniendesign

Auch eine eng gefasste Entscheidung hängt stark von den bereitgestellten Informationen und Anweisungen ab. Der Prompt sollte definieren, was als stützender Hinweis gilt, wie bei fehlenden Informationen vorzugehen ist und wie ein Grenzfall von einem eindeutigen Fall unterschieden wird.

Nehmen wir an, ein Team möchte Rechnungen weiterleiten. Eine schwache Frage könnte das Modell auffordern, „die richtige Abteilung auszuwählen“. Eine produktionsreife Frage würde die verfügbaren Abteilungen, die Felder zur Identifizierung jeder Abteilung, die Bedeutung eines unvollständigen Dokuments und die Regel für widersprüchliche Signale festlegen. Sie könnte außerdem ausdrücklich die Option human_review vorsehen, statt das Modell bei mehrdeutigen Eingaben zu einer Auswahl in einer Geschäfts-Warteschlange zu zwingen.

Die Beispiele sollten normale Fälle und Fehlersituationen abdecken. Dazu gehören kurze und lange Nachrichten, gemischte Sprachen, sofern das Produkt diese akzeptiert, widersprüchliche Datensätze, fehlende Felder, fehlerhaftes JSON und Versuche, Anweisungen in die Belegdaten einzuschleusen. Die Belegdaten sind Informationen. Sie dürfen die Entscheidungsrichtlinie nicht umschreiben.

Bei bildbezogenen Entscheidungen sollte festgelegt werden, was das Modell tatsächlich sehen kann und was es nicht feststellen kann. Ein Foto kann eine Delle zeigen, aber nicht beweisen, wodurch der Schaden entstanden ist. Ein Screenshot kann eine Fehlermeldung zeigen, aber nicht belegen, dass das Konto kompromittiert wurde. Der Antwortbereich sollte diesen Unterschied abbilden.

Wenn mehrere Fragen dasselbe Quelldokument oder dieselbe Unterhaltung betreffen, gehört das wiederverwendbare Material in den gemeinsamen Input; die Anweisungen für die jeweilige Frage können dann variieren. Die API unterstützt für dieses Muster Prompt-Caching. Laut Dokumentation muss der wiederverwendbare Präfix mindestens 1.024 Token enthalten; zwischengespeicherte Eingaben werden günstiger abgerechnet. Caching kann Kosten und Latenz senken. Entwickler müssen dabei jedoch die Cache-Grenzen verstehen und caller-spezifische oder sensible Inhalte nicht in einen Präfix legen, der im falschen Kontext wiederverwendet werden könnte.

Die Kosten sind niedrig, doch das Volumen verändert die Rechnung

Der veröffentlichte Preis für Decisions beträgt 0,10 US-Dollar pro Million nicht zwischengespeicherter Input-Token; zwischengespeicherte Eingaben kosten 0,01 US-Dollar pro Million Token. Für Output-Token fällt bei diesem Endpunkt keine Gebühr an. Auf den ersten Blick wirken viele Routing-Aufgaben damit nahezu kostenlos.

Die tatsächliche Rechnung hängt davon ab, wie viele Belege mit jeder Frage übertragen werden. Ein wiederholtes Richtliniendokument, ein Gesprächsverlauf oder eine Tool-Ausgabe kann deutlich größer sein als die eigentliche Anweisung. Derselbe umfangreiche Kontext, der für jede Entscheidung separat gesendet wird, widerspricht dem Zweck eines kleinen Klassifikators. Caching hilft bei einem stabilen Präfix, doch das Schreiben in den Cache und die regionale Verarbeitung können zusätzliche Kosten verursachen.

Teams sollten die Kosten pro abgeschlossenem Geschäftsvorgang messen, nicht pro API-Aufruf. Wenn ein Klassifikator einen Fall ablehnt und an eine manuelle Warteschlange weiterleitet, kann der Modellaufruf günstig sein, während der Gesamtprozess langsamer wird. Erzeugt ein automatisches Routing eine falsche nachgelagerte Aktion, können die Korrekturkosten die Tokenrechnung bei Weitem übersteigen.

Der Endpunkt kann in einer Anfrage viele unabhängige Fragen stellen. Das kann den Anfrage-Overhead verringern, sollte aber kein Anlass sein, zu jedem Vorgang jede denkbare Frage zu stellen. Zusätzliche Fragen erhöhen die Komplexität, erschweren die Bewertung und können Teams dazu verleiten, auf Scores zu reagieren, die niemand validiert hat.

Ein sinnvoller Pilot erfasst mindestens die Zahl der Input-Token, die Cache-Trefferquote, Latenz-Perzentile, die Verteilung der Antworten, die Prüfquote, die Korrekturquote und die Zeit bis zum Abschluss nachgelagerter Vorgänge. Bei interaktiven Produkten ist die p95-Latenz wichtiger als der Durchschnitt. Bei Backoffice-Warteschlangen können Durchsatz und Arbeitsaufwand der Prüfer stärker ins Gewicht fallen.

Datenschutz und regionale Kontrollen

Die API unterstützt eine Inferenzverarbeitung in den Vereinigten Staaten und Europa; OpenAI zufolge steht berechtigten Kunden außerdem Zero Data Retention zur Verfügung. Die Entwicklerdokumentation nennt für berechtigte Kunden auch HIPAA-Unterstützung und beschreibt die Verfügbarkeit von Private Link. Das sind nützliche Kontrollen. Die Organisation, die das System einführt, muss jedoch weiterhin Berechtigung, Verträge, Endpunktkonfiguration und Einschränkungen einzelner Funktionen prüfen.

Regionale Verarbeitung ist nicht gleichbedeutend mit einer vollständigen Datenschutzstrategie. Ein Team muss weiterhin entscheiden, ob der Input personenbezogene Daten enthält, ob die vollständige Akte tatsächlich übertragen werden muss, wie lange Anwendungslogs Anfrage und Antwort aufbewahren und wer Nutzungsberichte einsehen darf. Wo es praktikabel ist, sollten Daten vor dem Modellaufruf geschwärzt und minimiert werden.

Strukturiertes JSON macht sensible Informationen nicht automatisch sicher. Ein als input_json übergebener Kundendatensatz bleibt Kundendaten. Auch Bilder sind sensibel, wenn sie Gesichter, Adressen, medizinische Informationen oder vertrauliche Bildschirminhalte enthalten. Die entscheidende Frage lautet nicht, ob die API das Format akzeptiert, sondern ob es für den Workflow einen vertretbaren Grund gibt, diese Informationen zu übertragen.

Die gleiche Vorsicht gilt für Prompt-Caching. Ein stabiles Referenzdokument wiederzuverwenden, ist effizient. Einen Präfix mit privaten Daten eines Kunden über voneinander unabhängige Anfragen hinweg wiederzuverwenden, ist ein Designfehler. Cache-Schlüssel und -Grenzen sollten Teil der Prüfung des Datenflusses sein und nicht erst bei der nachträglichen Performance-Optimierung berücksichtigt werden.

Was Decisions nicht ersetzt

Der Endpunkt ist kein allgemeines Extraktionssystem. Benötigt die Anwendung ein umfangreiches Objekt mit vielen Feldern, eine schriftliche Erklärung oder eine Ausgabe nach einem eigenen Schema, ist die Responses API mit Structured Outputs möglicherweise besser geeignet. Muss das Modell ein Tool mit Argumenten anfordern, kann Function Calling die klarere Abstraktion sein.

Sie ist keine Regel-Engine. Eine deterministische Regel ist vorzuziehen, wenn sich die Bedingung exakt ausdrücken lässt. Beispielsweise sollte ein Konto nicht als berechtigt gelten, weil ein Modell mit hoher Sicherheit annimmt, dass der Kontostand unter einem Schwellenwert liegt. Die Anwendung kann den Kontostand direkt vergleichen.

Sie ist auch keine Sicherheitsfreigabe. Eine „sichere“ Auswahl eines Modells autorisiert keine unumkehrbare Aktion. Für alles, was Geld ausgeben, Zugriffsrechte ändern, extern eine Nachricht versenden, Produktionsdaten verändern oder Code ausführen kann, sollten Berechtigungen, Allowlists, Sandboxing, Transaktionslimits, Freigabeschritte und Audit-Logs eingesetzt werden.

In unklaren oder folgenreichen Fällen ersetzt sie keine menschliche Prüfung. Eine typisierte Antwort lässt sich leichter verarbeiten als Freitext, doch eine saubere Serialisierung kann ein unsicheres Urteil verbindlicher erscheinen lassen, als es ist. Das System sollte die Konfidenz, Verweise auf Belege und den Grund für die Eskalation bewahren.

Ein kleiner Pilot, der brauchbare Erkenntnisse liefern kann

Ein Team, das den Endpunkt in Betracht zieht, sollte mit einer wiederkehrenden Entscheidung beginnen, für die bereits ein messbares Ergebnis vorliegt. Ein Workflow, dessen Erfolg von fünf Modellaufrufen und mehreren schlecht definierten Übergaben abhängt, ist dafür kein guter Ausgangspunkt.

Zunächst sollte eine Stichprobe realer Eingaben gesammelt und von qualifizierten Prüfern mit der korrekten Aktion versehen werden. Die Labels müssen getrennt von den für Tests verwendeten Prompts bleiben. Schwierige und grenzwertige Beispiele gehören in die Stichprobe; nur offensichtliche Fälle auszuwählen, wäre irreführend.

Als Nächstes wird eine endliche Antwortmenge formuliert. Wenn Unsicherheit ein legitimes Ergebnis ist, sollte human_review aufgenommen werden. Für jede Antwort muss feststehen, was sie autorisiert und was nicht. Lässt sich die Aktion nicht klar beschreiben, ist die Entscheidung wahrscheinlich zu weit gefasst.

Danach werden drei Betriebsmodi getestet: automatische Weiterleitung oberhalb eines hohen Schwellenwerts, Prüfung in einem mittleren Bereich und ein sicherer Fallback unterhalb des niedrigeren Schwellenwerts. Diese Ergebnisse werden mit dem bisherigen Prozess verglichen. Ein Pilot, der lediglich die Modellgenauigkeit meldet, ohne die Belastung der Prüfer oder nachgelagerte Fehler zu messen, beantwortet die eigentliche Geschäftsfrage nicht.

Es sollten genügend Informationen protokolliert werden, um eine Entscheidung rekonstruieren zu können, ohne mehr sensible Daten als nötig zu speichern. Festgehalten werden sollten die Version der Frage, das Modell, der Schwellenwert, die Antwort, die Konfidenz, die ausgeführte Aktion und eine spätere Korrektur. Ändert sich ein Prompt, ist diese Änderung wie ein Software-Release zu behandeln; der Evaluationsdatensatz sollte erneut ausgeführt werden.

Schließlich sollte der Endpunkt zunächst neben dem bestehenden Workflow laufen, bevor er Aktionen steuern darf. Der Shadow-Modus kann zeigen, wo das Modell von erfahrenen Mitarbeitern abweicht, wo Belege fehlen und wo eine vermeintlich einfache Entscheidung eine Ausnahmebehandlung verbirgt.

Wer es ausprobieren sollte – und wer abwarten sollte

Die Decisions API ist für Teams einen Test wert, die bereits ein eng umrissenes Problem bei Klassifizierung, Routing, Scoring oder Eskalation haben, zulässige Ergebnisse definieren können und über genügend gelabelte Beispiele verfügen, um Änderungen zu bewerten. Besonders interessant ist sie, wenn der aktuelle Engpass in wiederholter Latenz während einer Live-Interaktion liegt oder darin, jede kleine Entscheidung durch einen größeren generativen Workflow zu schicken.

Sie kann auch zu Produkten passen, die mehrere unabhängige Fragen anhand desselben Textes, Bildes oder strukturierten Datensatzes bewerten müssen. Prompt-Caching und regionale Kontrollen sprechen zusätzlich für Workloads mit stabilem gemeinsamem Kontext und klaren Datenanforderungen.

Teams sollten abwarten, wenn sie noch nach einem Anwendungsfall suchen, nicht erklären können, wie eine korrekte Antwort aussieht, oder den Endpunkt beliebige Tools und Aktionen auswählen lassen wollen. Ein niedriger Tokenpreis rettet keine unklare Richtlinie. Ebenso darf eine schnelle Antwort nicht darüber hinwegtäuschen, dass Autorisierung, Prüfung oder Audit-Kontrollen fehlen.

Die weiterreichende Bedeutung der Veröffentlichung liegt in der Architektur. KI-Anwendungen entfernen sich von einer großen Anfrage, die alles zugleich verstehen, entscheiden und ausführen soll. Ein wartbareres System trennt diese Aufgaben: Ein Modell kann Belege interpretieren, ein begrenzter Entscheidungsendpunkt kann aus geprüften Optionen auswählen, und gewöhnliche Software kann Berechtigungen durchsetzen und das Ergebnis ausführen.

Diese Aufteilung beseitigt Modellfehler nicht. Sie macht sie jedoch leichter messbar, einzudämmen und zu korrigieren. Für die meisten Teams ist das der praktische Grund, Decisions zu testen – nicht, weil jeder Workflow einen weiteren KI-Endpunkt braucht, sondern weil manche Workflows eine kleinere und stärker verantwortete Entscheidungsschicht benötigen.