Decisions API: 2B or not 2B? Entscheidungsmodelle für KI-Agenten

Eine neue Modellklasse in zwei Wochen

Sein oder Nichtsein – für KI-Agenten lautet die Frage meist bescheidener: ja oder nein, rechts oder links, dringend oder nicht. Genau für solche Fragen ist eine neue Art von Modellen entstanden.

Im September 2026 hat das Start-up TypeSafe AI ein Modell namens Jev vorgestellt, das keine Texte schreibt, sondern nur entscheidet: Man gibt ihm eine Frage und feste Antwortmöglichkeiten, es liefert die Auswahl samt Wahrscheinlichkeit zurück – schnell und günstig. Innerhalb von zwei Wochen sind die Großen nachgezogen:

• OpenAI kündigte am 29. September auf der DevDay die Decisions API an.
• AWS veröffentlichte am 1. Oktober Strands Decider 2B als Open-Source-Modell.
• Cloudflare brachte am selben Tag die Modelle Clef und Clef-flash, ebenfalls quelloffen.

TypeSafe nennt diese Klasse „System One"-Modelle. Die Begriffe stammen aus der Kognitionspsychologie: Daniel Kahneman hat die Unterscheidung zwischen System 1 – schnellem, intuitivem Denken – und System 2 – langsamem, abwägendem Denken – mit seinem Buch „Schnelles Denken, langsames Denken" bekannt gemacht. Das schnelle System hat einen guten Grund: Wer vor einem Löwen erst in Ruhe abwägt, ob Weglaufen sinnvoll ist, hat schon verloren. Viele Entscheidungen müssen schnell und gut genug sein, nicht perfekt durchdacht. Übertragen auf KI ist ein großes Sprachmodell das abwägende System, ein Entscheidungsmodell das schnelle. Für alle, die KI-Agenten in Prozesse einbauen, lohnt ein genauer Blick. Denn viele Entscheidungen, die heute ein großes Sprachmodell trifft, könnte ein solches Modell schneller, billiger und berechenbarer treffen.

Was ein Entscheidungsmodell anders macht

Ein klassisches Sprachmodell erzeugt Text, Wort für Wort. Will man eine Entscheidung von ihm, muss man die Antwort aus dem Text herauslesen und hoffen, dass sie das erwartete Format hat. Ein Entscheidungsmodell dagegen:

• wählt immer aus den vorgegebenen Optionen – Ja/Nein, eine aus mehreren Kategorien oder eine Bewertung auf einer Skala,
• liefert zu jeder Antwort eine Wahrscheinlichkeit, mit der sich weiterarbeiten lässt: über einer Schwelle automatisch handeln, darunter einen Menschen fragen,
• antwortet in einem einzigen Durchlauf, ohne Text zu erzeugen – und damit sehr schnell,
• beantwortet mehrere Fragen zum selben Text günstig, weil der Text nur einmal gelesen wird.

AWS bringt den Vorteil auf den Punkt: Eine verlässliche Angabe, wie sicher eine Ja/Nein-Entscheidung ist, liefern die Schnittstellen großer Sprachmodelle nicht.

Typische Einsatzfälle

Die Anbieter nennen weitgehend dieselben Beispiele:

• Anfragen weiterleiten: Ist dieses Support-Ticket dringend? Welches Team ist zuständig?
• Modelle auswählen: Braucht diese Aufgabe das große, teure Modell oder reicht ein kleines?
• Werkzeuge wählen: Welches Werkzeug soll der Agent als Nächstes nutzen?
• Argumente prüfen: Stammen die Werte, mit denen der Agent ein Werkzeug aufrufen will, wirklich aus den Angaben des Nutzers – oder hat er sie erfunden?
• Leitplanken: Verstößt eine Antwort gegen eine Richtlinie? Ist sie durch die Quellen gedeckt?

Das Muster dahinter ist eine Arbeitsteilung: Das große Sprachmodell übernimmt die schwierigen Aufgaben, das Entscheidungsmodell die vielen kleinen Routineentscheidungen dazwischen. OpenAI setzt das selbst so ein: Im quelloffenen Code von Codex nutzt eine Sicherheitskomponente die Decisions API, um das Risiko von Agentenaktionen als niedrig oder hoch einzustufen.

flowchart TD
    T[Schritt im Agenten-Ablauf] --> Q{Einfache Entscheidung?}
    Q -->|ja| D[Entscheidungsmodell]
    Q -->|nein, komplexe Aufgabe| LLM[Großes Sprachmodell]
    D --> W{Wahrscheinlichkeit über Schwelle?}
    W -->|ja| AUTO[Automatisch weiter]
    W -->|nein| MENSCH[Mensch entscheidet]

Warum Wahrscheinlichkeiten den Unterschied machen

Dass ein Entscheidungsmodell eine Wahrscheinlichkeit liefert statt nur einer Antwort, klingt nach einem Detail. Tatsächlich ist es der Kern des Ansatzes – und dahinter steckt solide Mathematik.

Die Schwelle ergibt sich aus den Kosten. Ein gut kalibriertes Modell schätzt, wie wahrscheinlich eine Antwort zutrifft – im Sinne des Satzes von Bayes die Wahrscheinlichkeit einer Antwort unter der gegebenen Eingabe. Ob man darauf automatisch handelt, hängt davon ab, was ein Fehler kostet. Die Bayes'sche Entscheidungstheorie liefert dafür eine einfache Regel: Automatisch handeln lohnt sich, wenn die Wahrscheinlichkeit über

Kosten einer falschen Aktion / (Kosten einer falschen Aktion + Kosten einer unnötigen Rückfrage)

liegt. Ist ein fälschlich geschlossenes Support-Ticket neunmal so teuer wie eine unnötige Rückfrage, liegt die Schwelle bei 90 %. Damit wird aus dem Bauchgefühl „das Modell ist sich ziemlich sicher" eine begründete Grenze. Ein Sprachmodell, das nur „Ja, das ist dringend" schreibt, liefert diese Zahl nicht.

Ketten von Entscheidungen werden schnell unsicher. Ein Agenten-Ablauf ist ein Graph aus Schritten, und an jeder Verzweigung fällt eine Entscheidung. Damit der ganze Ablauf stimmt, müssen alle Entscheidungen entlang des Pfads stimmen – die Wahrscheinlichkeiten multiplizieren sich. Das Prinzip kennt jeder vom Münzwurf: Kopf fällt mit einer Wahrscheinlichkeit von 1/2, dreimal hintereinander Kopf aber nur mit 1/2 · 1/2 · 1/2 = 1/8. Bei Agenten sind die einzelnen Wahrscheinlichkeiten zum Glück viel höher, das Prinzip bleibt dasselbe: Fünf Entscheidungen mit je 95 % Trefferquote ergeben zusammen nur noch etwa 77 %, zehn nur noch etwa 60 %. Jede einzelne Entscheidung wirkt zuverlässig, der Gesamtablauf ist es nicht.

flowchart TD
    T[Ticket geht ein] --> K{"Welche Kategorie?<br/>95 %"}
    K --> D{"Dringend?<br/>95 %"}
    D --> Z{"Welches Team?<br/>95 %"}
    Z --> A["Automatisch zugewiesen<br/>gesamt etwa 86 %"]
    D -.->|unter der Schwelle| M[Ein Mensch prüft]

Daraus folgen zwei Regeln für die Praxis: Automatische Ketten kurz halten, und an den Stellen, an denen ein Fehler teuer wird oder sich durch den weiteren Ablauf zieht, bewusst eine Rückfrage an einen Menschen einbauen.

Kalibrierung gilt nur für bekannte Daten. Kommen in Ihrem Betrieb manche Antworten viel seltener vor als in den Trainingsdaten, sind die Wahrscheinlichkeiten zu optimistisch – auch das lässt sich mit dem Satz von Bayes korrigieren, wenn man die tatsächlichen Häufigkeiten kennt. Und wie die JevOut-Studie zeigt, kann ungewöhnlicher Kontext ein Modell auch dazu bringen, sich sehr sicher zu irren. Eine Wahrscheinlichkeit ist keine Wahrheit, sondern die Einschätzung des Modells über seine eigene Unsicherheit. Deshalb lohnt es sich, sie mit eigenen Beispielen nachzuprüfen.

Die Angebote im Überblick

OpenAI Decisions API: Basiert auf dem Modell GPT-6 Luna und nimmt Text oder Bilder als Kontext. Laut OpenAI ist sie seit dem 29. September in einer eingeschränkten Vorschau verfügbar, eine breite Veröffentlichung sei „in den kommenden Tagen" geplant. Eine Dokumentation und Preise gab es bei Redaktionsschluss noch nicht.

AWS Strands Decider 2B: Ein Modell mit 1,9 Milliarden Parametern auf Basis von Qwen, veröffentlicht von AWS Strands Labs. Code, Gewichte und Trainingsdaten sind offen, das Modell läuft auf einer Grafikkarte, einem Mac mit Apple-Chip oder auf dem Prozessor. Die Einbindung erfolgt über ein Python-Paket, eine Kommandozeile oder einen HTTP-Server. AWS beschreibt es ausdrücklich als Modell zum Experimentieren und für die lokale Entwicklung.

Cloudflare Clef: Zwei Modelle, die Cloudflare auf Workers AI hostet und zugleich unter Apache 2.0 auf Hugging Face veröffentlicht hat. Sie sind mit der Schnittstelle von Jev kompatibel. Cloudflare nutzt Clef nach eigenen Angaben bereits intern, etwa um Websites für die Bedrohungsanalyse zu klassifizieren.

Nebeneffekt: weniger Rechenaufwand

Ein großes Sprachmodell erzeugt seine Antwort Wort für Wort, und jedes Wort ist ein vollständiger Durchlauf durch ein oft sehr großes Modell – auch wenn am Ende nur „Ja" dasteht. Ein Entscheidungsmodell liest den Text einmal und wählt in einem einzigen Durchlauf. Das spart Rechenzeit und damit Energie pro Entscheidung, und es entlastet die knappen Rechenkapazitäten der Anbieter. Cloudflare nennt ein Beispiel aus dem eigenen Betrieb: Für dieselbe Klassifizierung einer Website – samt Abruf und Darstellung der Seite – brauchte Clef 2,2 Sekunden, das schnellste allgemeine Sprachmodell im selben Ablauf 4,7 Sekunden.

Eine Einschränkung gehört dazu: Wenn Entscheidungen billig werden, trifft man meist mehr davon. Weniger Aufwand pro Entscheidung bedeutet deshalb nicht automatisch weniger Verbrauch insgesamt.

Und was ist mit klassischem Machine Learning?

Klassifizieren, Stimmungen erkennen, Betrug aufspüren – das konnte maschinelles Lernen schon lange vor den Sprachmodellen. Mit ML.NET gibt es dafür sogar ein Open-Source-Framework direkt für .NET, das Microsoft selbst in Produkten wie Power BI, Defender und Outlook einsetzt. Wo liegt also der Unterschied?

Ein klassisches Modell wird für genau eine Aufgabe mit eigenen, gelabelten Daten trainiert: etwa ein Stimmungsmodell aus Tausenden bewerteten Kundenrezensionen. Es kennt danach nur diese eine Frage und diese Kategorien. Ein Entscheidungsmodell bringt dagegen allgemeines Sprachverständnis mit; Frage und Antwortmöglichkeiten werden erst bei der Anfrage festgelegt.

Kurz erklärt:

• Klassifikation ordnet etwas einer festen Kategorie zu: Kopf oder Zahl, dringend oder nicht, positive oder negative Bewertung. Genau das können auch Entscheidungsmodelle.
• Regression sagt eine Zahl voraus statt einer Kategorie: den Preis einer Fahrt, den Absatz im nächsten Monat, die Laufzeit einer Maschine. Dafür sind Entscheidungsmodelle nicht gebaut.
• Overfitting heißt, dass ein Modell seine Trainingsdaten auswendig lernt, statt das dahinterliegende Muster zu verstehen – wie ein Schüler, der die Lösungen alter Prüfungen kennt, aber bei einer neuen Aufgabe scheitert. Auf bekannten Daten glänzt es, im Alltag versagt es.

Die Faustregel daraus: Wer viele eigene, gelabelte Daten hat und dieselbe Frage dauerhaft stellt, fährt mit klassischem Machine Learning meist günstiger und genauer. Ein Modell, das seit Jahren Rechnungen nach denselben Kategorien sortiert, braucht kein Sprachverständnis. Für vieles bleibt ML ohnehin erste Wahl: Absatzprognosen und Preisvorhersagen (also Regression), Produktempfehlungen oder Kundensegmentierung – also das Bilden von Gruppen ohne vorgegebene Antworten – sind keine Fragen mit festen Antwortmöglichkeiten und damit kein Fall für ein Entscheidungsmodell.

In einem internen Experiment haben wir ML.NET – passend zum Münzwurf weiter oben – für die Bilderkennung von Münzen eingesetzt – bis hin zur Live-Erkennung über eine Webcam mit OpenCV. Kopf oder Zahl erkannte das Modell sehr zuverlässig. Beim Nennwert war es schwieriger: Es gibt mehr Klassen, bei Euromünzen ist die Verteilung sehr unterschiedlich, und bei den Cent-Münzen tragen mehrere Nennwerte auf der Kopfseite dasselbe Motiv – in Deutschland etwa der Eichenzweig auf 1, 2 und 5 Cent oder das Brandenburger Tor auf 10, 20 und 50 Cent.

Die eigentliche Arbeit steckte dabei nicht im Algorithmus, sondern in der Aufbereitung der Bilder und den Trainingseinstellungen. Mit zufällig um bis zu 30 Grad gedrehten Trainingsbildern erreichte das Modell nur rund 23 % Genauigkeit, mit einer Gewichtung der unterschiedlich häufigen Klassen 42 %, bei 15 Grad Drehung 64 %. Ohne Drehung, mit Gewichtung und ohne Helligkeitsvariation waren es 85 %, mit einer kleineren Lernrate je nach Durchlauf zwischen 78 und 89 %. Dieselbe Technik, ganz unterschiedliche Ergebnisse – je nachdem, wie die Daten vorbereitet werden.

Der Grund lag in den Trainingsdaten: Wir hatten mit Fotos aus dem Internet trainiert. Dort liegen Münzen immer gerade, sind perfekt ausgeleuchtet, sauber und ohne Spiegelungen. So sieht eine Münze vor der Webcam selten aus: Sie liegt schief, spiegelt und ist mal heller, mal dunkler. Das ist eng verwandt mit Overfitting: Das Modell passt perfekt zu seinen Trainingsbildern, aber nicht zur Welt, in der es eingesetzt werden soll. Das Modell lernte deshalb vor allem, solche Idealbilder zu erkennen – künstliche Drehungen und Helligkeitsschwankungen passten nicht zu diesen Daten und drückten die gemessene Genauigkeit. Eine hohe Zahl auf sauberen Testbildern sagt also wenig darüber, wie gut ein Modell mit schief liegenden, spiegelnden Münzen im Alltag zurechtkommt.

Die Lehre daraus gilt weit über Münzen hinaus: Wenige, klar unterscheidbare Klassen lernt klassisches Machine Learning schnell und genau. Bei vielen, ungleich verteilten oder kaum unterscheidbaren Klassen entscheiden Datenaufbereitung, Gewichtung und Feinabstimmung über das Ergebnis – und vor allem Trainingsdaten, die der echten Nutzung entsprechen. Genau dort liegt der Aufwand.

Entscheidungsmodelle spielen ihre Stärken aus, wenn Daten fehlen, sich die Fragen häufig ändern oder Texte zu vielfältig sind. Beides lässt sich auch gut verbinden: Man startet mit einem Entscheidungsmodell, lässt unsichere Fälle von Menschen entscheiden – und hat damit nach einiger Zeit genau die gelabelten Daten, mit denen sich ein schlankes klassisches Modell trainieren lässt.

Für deutsche Unternehmen: lokal ist ein echtes Argument

Gerade bei Routineentscheidungen fließen oft personenbezogene Daten: Support-Tickets, E-Mails, Kundenanfragen. Bei einer Cloud-Schnittstelle stellt sich für jede dieser Entscheidungen die Frage, wo die Daten verarbeitet werden. Für die Decisions API ist das noch offen: In OpenAIs Übersicht zu Datenhaltung und Zero Data Retention taucht sie bislang nicht auf.

Die offenen Modelle von AWS und Cloudflare lassen sich dagegen im eigenen Haus betreiben. Für die Klassifizierung eines Tickets müssen die Daten das Unternehmen dann gar nicht verlassen. Das passt zu dem, was wir in Lokale Sprachmodelle im Unternehmen: welche Hardware reicht? beschrieben haben – mit dem Unterschied, dass ein Modell dieser Größe deutlich bescheidenere Hardware braucht.

Ein Beispiel, wie das aussehen kann: Eine Versicherung prüft eingehende Schadensmeldungen. Ein im eigenen Rechenzentrum betriebenes Entscheidungsmodell beantwortet für jede Meldung Fragen wie „Ist der Schaden vom Vertrag gedeckt?" oder „Sind die Unterlagen vollständig?" – jeweils mit Wahrscheinlichkeit und ohne dass Meldung oder Gesundheitsdaten das Haus verlassen. Eindeutige Fälle werden zügig bearbeitet, unsichere landen bei der Sachbearbeitung.

Sinnvoll ist dabei eine klare Asymmetrie: Eindeutige Zusagen kann das System beschleunigen, eine Ablehnung prüft immer ein Mensch.

Was man nicht übersehen sollte

Sie sind nicht für alles geeignet. AWS sagt selbst, dass ein Entscheidungsmodell bei komplexen Problemen deutlich schlechter abschneidet als ein Reasoning-Modell und für Texte, Code oder Zusammenfassungen ungeeignet ist. Auf einem unabhängigen Benchmark für diese Modellklasse liegen große Reasoning-Modelle klar vorn; kleine Modelle wie der Strands Decider spielen im Mittelfeld.

Deutsch ist ungetestet. Für den Strands Decider ist die Sprachunterstützung nicht dokumentiert, die Trainingsdaten sind überwiegend englisch. Wer deutsche Tickets oder E-Mails klassifizieren will, sollte das mit eigenen Beispielen prüfen, bevor er sich darauf verlässt.

Sie lassen sich täuschen. Eine im September veröffentlichte Studie mit dem Titel „JevOut" zeigt, dass kurzer, ganz normal aussehender Zusatzkontext Entscheidungsmodelle zu falschen Antworten mit hoher Sicherheit bringen kann. Bei Jev kippten so 61 % der zuvor richtigen Entscheidungen, bei drei weiteren Systemen zwischen 65 und 73 %. Wer ein Entscheidungsmodell als Sicherheitsschranke einsetzt, sollte es deshalb nicht als einzige Schranke einsetzen – und hohe Wahrscheinlichkeiten nicht mit Richtigkeit verwechseln.

Die Technik ist jung. Alle Angebote sind wenige Wochen alt, teils in der Vorschau oder in Version 0.1. Für einen Pilotversuch reicht das, für einen kritischen Prozess noch nicht.

Wo wir stehen

Entscheidungsmodelle haben wir selbst noch nicht produktiv im Einsatz – die Modellklasse ist dafür schlicht zu jung. Aus dem täglichen Arbeiten mit KI-Agenten kennen wir aber das Problem, das sie lösen sollen: Viele Schritte eines Agenten sind keine schwierigen Aufgaben, sondern einfache Ja/Nein- oder Entweder-oder-Entscheidungen, für die ein großes Modell überdimensioniert ist. Genau dort würden wir ansetzen.

Unsere Einschätzung

Entscheidungsmodelle sind eine sinnvolle Ergänzung für jeden, der KI-Agenten in Prozesse einbaut. Sie machen aus einer vagen Textantwort eine Zahl, auf die der eigene Code reagieren kann: Über einer Schwelle läuft der Prozess automatisch weiter, darunter entscheidet ein Mensch. Das macht Agenten berechenbarer und günstiger.

Für den Einstieg empfehlen wir einen kleinen Test mit echten, anonymisierten Beispielen aus dem eigenen Haus – etwa einer Stichprobe aus dem Ticketsystem. Ein lokales Modell genügt dafür, und man sieht schnell, ob die Qualität für Deutsch und die eigenen Kategorien reicht.

Sie möchten Entscheidungsmodelle in Ihre Prozesse oder Agenten einbauen – auch mit .NET? Mehr zu unserem Angebot finden Sie unter KI-Agenten für Unternehmen. Oder sprechen Sie uns direkt an.

Quellen: OpenAI – DevDay 2026 Recap · AWS Strands – Introducing Strands Decider 2B · GitHub – strands-labs/strands-decider · Microsoft – ML.NET · Hugging Face – Strands Decider 2B · Cloudflare – Introducing Clef · GitHub – Codex Guardian (Decisions-Client) · arXiv – JevOut: Natural Context Can Flip Decision Models · TechCrunch – OpenAI's Jev clone · The New Stack – OpenAI Decision API