Decision Engine: KI-Entscheidungen per API

Die Decision Engine trifft kleine, wiederkehrende Entscheidungen mit KI: welches Team ein Ticket bekommt, wie dringend ein Schreiben ist, ob ein Mensch prüfen muss. Statt eines Textes liefert sie Wahrscheinlichkeiten über feste Antwortmöglichkeiten, die Ihre Software direkt weiterverarbeiten kann. Sie ist per API, im Chat, per MCP und im Playground nutzbar.

So funktioniert es

Sie schicken einen Zustand (Text, JSON, einen Gesprächsverlauf, auf Wunsch Bilder) und Fragen mit festen Antworten. Die Engine liest ab, wie wahrscheinlich jede erlaubte Antwort ist, und gibt diese Werte zurück. Einen Satz schreibt sie dabei nicht. Das Sprachmodell formuliert, die Decision Engine bewertet, und Ihre Regeln bestimmen, was danach passieren darf.

Bekannt gemacht hat dieses Prinzip TypeSafe AI mit dem Produkt Jev. Die Decision Engine setzt es mit offenen Grundmodellen in EU-Rechenzentren um und speichert den Zustand nicht. Mit Jev oder anderen fremden Produkten haben wir sie nicht verglichen.

Drei Frageformate

• Auswahl (choice): eine von 2 bis 26 Optionen, etwa Team, Kategorie oder nächste Aktion.
• Ja/Nein (binary): Trifft eine Aussage zu? Etwa Prüfbedarf, Beschwerde, Eskalation.
• Bewertung (score): eine Stufe auf einer geordneten Skala, etwa Dringlichkeit.

Eigene Fragen legen Sie frei fest. Für häufige Aufgaben gibt es zehn fertige Vorlagen; Fragen, Optionen und Beispiele stehen unter Anwendungsfälle:

• Ticket-Routing (ticket-routing-v1): Team, Dringlichkeit und Prüfbedarf einer Support-Nachricht.
• Posteingang-Klassifikation (inbox-document-v1): Dokumentart, Frist und Handlungsbedarf eines Schreibens.
• Kundenfeedback-Analyse (customer-feedback-v1): Stimmung, Abwanderungsrisiko und Antwortbedarf.
• Lead-Qualifizierung (lead-qualification-v1): Passung, Zeithorizont und Budget einer Vertriebsanfrage.
• Behörden-Posteingang (behoerden-posteingang-v1): Anliegen, Zuständigkeit, Frist und Eskalation.
• Antrag vollständig? (antrag-vollstaendigkeit-v1): formale Vorprüfung eines Antrags (JSON).
• Freigabe-Check Veröffentlichung (veroeffentlichung-check-v1): Datenschutz und Ton vor dem Veröffentlichen.
• Agenten-Weiche (agent-handoff-v1): welchen Weg ein KI-Assistent nimmt.
• Quellentreue-Prüfung (grounding-check-v1): ob eine RAG-Antwort von ihren Quellen gedeckt ist (JSON).
• Agenten-Schritt freigeben (agent-step-risk-v1): ob ein Agent einen geplanten Schritt ausführen darf (JSON).

So nutzen Sie die Decision Engine

• Playground: eingeloggt über die Seitenleiste → Decision Engine, mit echter Inferenz.
• API: POST /v1/decisions mit dem Scope decisions. Die Modelle sovr-decision-v1 und sovr-decision-v2 stehen auch unter GET /v1/models.
• Chat: Die Pille Entscheiden im Eingabefeld schaltet das Werkzeug decision_engine frei. Das Sprachmodell ruft es mit einer Vorlage oder eigenen Fragen auf und fasst das Ergebnis zusammen. So testen Sie eine Vorlage an echten Texten.
• MCP: Der authentifizierte MCP-Server bietet sovrgpt_decide (Entscheidung mit Vorlage oder eigenen Fragen) und sovrgpt_list_decision_presets (Vorlagen mit Beispielzuständen). Der Schlüssel braucht den Scope decisions.

Alle Wege nutzen dieselben Laufzeiten und Vorlagen.

Automatik mit Empfehlung

Jede Antwort trägt eine Empfehlung. recommendation: "act" heißt, Ihre Software kann weitermachen; "review" heißt, vorher sollte ein Mensch hinschauen. Die Gründe stehen in reasons, etwa eine Wahrscheinlichkeit unter der Schwelle, eine gewählte Enthaltung wie unclear oder eine Antwort, die bei umsortierten Optionen anders ausfällt.

Wie viel automatisch laufen darf, steuern Sie mit policy.mode:

Im Modus autonomous sollte Ihre Anwendung selbst auf Warnsignale reagieren, etwa mit einem sicheren Standardverhalten.

Bis zum 23.09.2026 war review_only die Vorgabe, ohne Doppelprüfung. Dieses Verhalten zu den bisherigen Kosten bekommen Sie mit "policy": { "mode": "review_only", "stability_check": false }.

Doppelprüfung

Eine Auswahlantwort kann allein durch die Reihenfolge der Optionen kippen, auch bei einer angezeigten Wahrscheinlichkeit nahe 100 %. Deshalb stellt die Engine jede Auswahlfrage standardmäßig ein zweites Mal mit umsortierten Optionen, parallel zum ersten Durchlauf. Weichen die Antworten ab, lautet die Empfehlung review (bei autonomous nur ein Warnsignal in reasons). Scheitert nur der zweite Durchlauf, trägt die Antwort das Warnsignal stability_unavailable.

Die Doppelprüfung schützt vor Antworten, die nur dank einer glücklichen Reihenfolge stimmen. Genauer macht sie das Modell nicht: Liegt es in beiden Reihenfolgen gleich falsch, meldet sie nichts. Sie kostet bei Auswahlfragen doppelte Eingabetoken und lässt sich mit "stability_check": false abschalten. Alle Warnsignale stehen in der API-Referenz.

Zwei Versionen

Beide laufen auf offenen Grundmodellen; welche Laufzeit rechnet, legen wir fest. Welche Version ohne Angabe gilt, stellen Owner oder Admin Ihrer Organisation unter Decision Engine ein.

Wie schnell ist eine Entscheidung?

Eine Chat-Antwort entsteht Token für Token. Eine Entscheidung braucht je Frage einen einzigen Modelldurchlauf, bei Auswahlfragen mit Doppelprüfung zwei parallele; mehrere Fragen laufen gleichzeitig.

Warm gemessen braucht v1 etwa 65 ms je Frage, v2 etwa 200 ms; vier Fragen gleichzeitig dauern etwa doppelt so lange. Eine Chat-Antwort zum selben Text braucht 5 bis 30 Sekunden. Das sind Messwerte ohne Doppelprüfung, keine Zusage; deren Aufschlag haben wir noch nicht nachgemessen. Die tatsächliche Dauer steht in jeder Antwort unter timing_ms.

Bilder funktionieren als Zustand, brauchen aber deutlich länger. Wie lange, haben wir nicht gemessen.

Was die Zahlen nicht sagen

• Die Werte sind unkalibriert. 0,92 heißt „92 % der Wahrscheinlichkeitsmasse liegen auf dieser Option“, nicht „zu 92 % richtig“.
• Ein Modell kann mit voller Sicherheit falsch liegen. Ein leeres reasons heißt „nichts Auffälliges gefunden“, nicht „sicher richtig“.
• recommendation ist eine Empfehlung an Ihren Workflow. Die Engine selbst handelt nie.
• Der Zustand wird als Daten behandelt, nie als Anweisung. Er wird nicht gespeichert; abgerechnet werden nur Tokenzahlen.

Genauigkeitswerte nennen wir erst nach Kalibrierung und Qualitätsberichten je Vorlage. Bis dahin: Prüfen Sie eine Vorlage an einer Stichprobe Ihrer echten Vorgänge, am besten mit review_only, bevor Sie Entscheidungen automatisch durchlaufen lassen.