Jev: Ein KI-Modell, das entscheidet statt schreibt

In den beiden Beiträgen zur Automatisierung von Prozesseb via n8n stand zentraler der Gedanke, der beim Bau automatisierter Abläufe meistens den Ausschlag gibt: Der Modellaufruf ist nur einer von vielen Schritten, und ein großer Teil Arbeit besteht darin, das Ergebnis so einzufassen, dass zuverlässig damit weitergearbeitet werden kann. Verlangt wird eine strukturierte Antwort, die gegen die eigenen Regeln geprüft wird und gibt sie im Zweifel an einen Menschen weiter. Das funktioniert, ist an sich aber ein Umweg. Ein LLM bzw. Sprachmodell ist dazu gebaut, Text zu generieren, und im Ablauf der Automatisierung wird viel Aufwand darauf verwendet, diese Eigenschaft so umzubiegen, dass aus Prosa eine strukturierte Antwort wird.

Am 15. September 2026 hat das Start-up TypeSafe AI aus San Francisco, ausgestattet mit 40 Millionen US-Dollar Startkapital, ein Modell vorgestellt, das diesen Umweg von der anderen Seite angeht. Jev schreibt keinen Text, sondern bekommt einen Sachverhalt und eine Reihe genau umrissener Fragen (in Form einer festen Struktur) und liefert jede Antwort aus einem vorher festgelegten Wertebereich, zusammen mit einer Angabe darüber, wie sicher die Antwort ist ("Konfidenz", auch bekannt aus dem Stochastikgrundkurs der Hochschule). Der Hersteller spricht dabei von einer neuen Modellklasse und nennt sie „System One“.

Ich habe mir Dokumentation, Herstellerangaben und die ersten unabhängigen Einschätzungen angesehen. Dieser Beitrag ordnet ein, was Jev für KI-gestützte Automatisierung bedeutet, wo es gängigen Sprachmodellen tatsächlich voraus ist und was vor einem Einsatz in einem deutschen Betrieb noch geklärt sein muss.

Was Jev anders macht

Ein Sprachmodell wie ChatGPT oder Claude erzeugt seine Antwort Wort für Wort. Das ist die Stärke dieser Modelle, wenn am Ende ein Text stehen soll (oder um im Chat-Modus einfacher anthropomorphisiert zu werden), und gleichzeitig Schwäche, wenn als Ergebnis eine konkrete maschinelle Entscheidung gewünscht ist. Fragt man ein Sprachmodell, welcher Abteilung eine eingehende Mail zuzuordnen ist, erhält man als Antwort im besten Fall genau das gewünschte Wort im gewünschten Feld. Im schlechten Fall halluziniert es eine Abteilung, die es nicht gibt und versteckt die gelogene Antwort in einen höflichen Satz. Teilweise werden auch strukturierte Antworten geliefert, wenn gefordert, bspw. JSON-Objekte, diese sind aber nicht zuverlässig richtig oder in der geforderten Form. Was diese Antworten nicht mitliefern, ist eine belastbare Aussage darüber, wie sicher die Entscheidung des Modells war: Eine falsche Antwort wird in aller Regel genauso selbstbewusst formuliert wie eine richtige.

Jev dreht diese Aufgabe um. Die möglichen Antworten stehen vorher fest, und das Modell verteilt Wahrscheinlichkeiten auf diese. Dafür gibt es drei Fragetypen. Eine Choice wählt aus bis zu 255 vorgegebenen Optionen die zutreffende aus, etwa die zuständige Abteilung. Ein Score ordnet den Fall auf einer selbst beschriebenen Skala ein, zum Beispiel von „keine Eile“ bis „heute noch“. Ein Noul beantwortet eine Ja-Nein-Frage mit der Wahrscheinlichkeit, dass die Antwort Ja lautet. Mehrere solcher Fragen gegen denselben Sachverhalt werden in einem einzigen Aufruf parallel beantwortet.

Eine Anfrage für die Vorsortierung eines Sammelpostfachs sieht dann ungefähr so aus, hier auf Englisch, weil Jev in dieser Sprache am verlässlichsten arbeitet (dazu weiter unten mehr):

{
  "model": "jev-1.13.0",
  "state": "Hello, invoice 2026-0815 was debited from our account twice. Please sort this out by Friday.",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which department is responsible for this request?",
      "criteria": {
        "accounting": "Invoices, payments, credit notes",
        "sales": "Quotes, new orders, pricing",
        "service": "Complaints, repairs, maintenance"
      }
    },
    "deadline_stated": {
      "type": "noul",
      "instructions": "Does the sender state a deadline by which they expect a reply?"
    }
  }
}

Zurück kommen für die erste Frage die gewählte Abteilung, die Wahrscheinlichkeit jeder der drei Optionen und ein daraus berechneter Konfidenzwert, für die zweite eine Zahl zwischen 0 und 1. Eine vierte Abteilung kann dabei schlicht nicht herauskommen, und es ist auch nicht nötig etwas zu parsen, was an einem fehlenden Anführungszeichen scheitern könnte, denn das Antwortformat ist fest vom Nutzer vorgegeben.

Was „keine Halluzinationen“ tatsächlich heißt

Der Hersteller wirbt damit, dass Jev nicht halluziniert. Das stimmt zwar, aber in einem engeren Sinn, als das Wort nahelegt. Gemeint ist damit, dass jede Antwort immer im vorgegebenen Wertebereich liegt: Ein Formatfehler oder eine erfundene Option ist durch die Bauweise ausgeschlossen. Ein Modell, das nur zwischen drei Abteilungen wählen darf, kann trotz dieser Einengung des Lösungsraums mit großer Sicherheit die falsche wählen. Formfehler werden also zuverlässig vermieden, inhaltliche Fehler nicht.

Was sich tatsächlich ändert, ist, dass das Modell seine Unsicherheit mitteilt. Das Training zielt darauf, dass die Konfidenz kalibriert ist, d.h. von allen Antworten, die mit ca. 90 Prozent Konfidenz gegeben werden, sollen also auch rund neun von zehn stimmen. Das ist eine Aussage über viele Fälle im Allgemeinen und keine über einen speziellen, und sie stammt bislang vom Hersteller selbst. Eine unabhängige Überprüfung gibt es noch nicht. Das Versprechen verdient trotzdem Aufmerksamkeit, denn es ist genau die Eigenschaft, die den weit verbreiteten Sprachmodellen fehlt.

Warum der Ansatz zu Automatisierung passt

Die Konfidenz wird zur Weiche. Im ersten n8n-Beitrag habe ich die These erhoben, dass ein Ablauf, der neunzig Prozent der Fälle selbst erledigt und zehn Prozent an einen Menschen weitergibt, mehr wert ist als einer, der alles erledigt und dabei viele Fehler produziert. Mit einem Sprachmodell muss man sich die Grundlage für diese Aufteilung selbst bauen, mit Plausibilitätsregeln, einem zweiten Modellaufruf zur Kontrolle oder regelmäßigen Stichproben. Bei Jev ist sie fester Teil jeder Antwort, bzw. sogar ein großer Teil des grundlegenden Wertversprechens. Die Dokumentation empfiehlt drei Bereiche: Bei hoher Konfidenz handelt der Ablauf selbst, bei mittlerer legt er einen Vorschlag zur Bestätigung vor, und bei niedriger übergibt er den Fall an einen Menschen. Die Schwellen dürfen und sollen sich dabei nach dem Risiko des nächsten Schritts richten. Eine Mail in den falschen Ordner zu legen, ist schnell korrigiert, eine Gutschrift an den falschen Kunden nicht. In n8n wäre das nichts weiter als eine Verzweigung hinter dem Modellaufruf, und es ist zugleich die einfachste Form menschlicher Aufsicht, die sich später im Protokoll auch nachweisen lässt.

Geschwindigkeit und Kosten verschieben die Grenze des Machbaren. Der Hersteller nennt Antwortzeiten zwischen 70 und 500 Millisekunden und einen Preis von 0,042 US-Dollar pro Million eingegebener Token, die Ausgabe kostet nichts. Für eine Beispielaufgabe gibt er 0,114 Sekunden und 0,000081 US-Dollar pro Durchlauf an, gegenüber 8,6 Sekunden und 0,0139 US-Dollar bei Anthropics Modell Fable 5.1. Diese Zahlen stammen aus einem einzelnen Beispiel und hängen stark von der Länge der Eingabe ab, sie eignen sich aber gut, um einmal durchzurechnen, wann der Unterschied zählt.

Ein Betrieb, der täglich 200 eingehende Mails vorsortiert, trifft an 250 Arbeitstagen rund 50.000 solcher Entscheidungen im Jahr. Mit Jev kosten sie nach dieser Rechnung etwa 4 US-Dollar, mit dem großen Sprachmodell etwa 700 (wobei Fable hier auch maßlos überdimensioniert ist). Beides ist gemessen an dem, was Aufbau und Pflege des Ablaufs kosten, vernachlässigbar, und ob eine Mail nach einer Zehntelsekunde oder nach neun Sekunden im richtigen Ordner liegt, merkt niemand. Für diesen typischen Fall ist Jev also kein Grund umzustellen.

Anders sieht es aus, wenn einmalig 100.000 Artikelstammsätze auf Duplikate geprüft oder Warengruppen zugeordnet werden sollen. Hier stehen etwa 8 US-Dollar und gut drei Stunden Laufzeit gegen knapp 1.400 US-Dollar und, ohne Parallelisierung, rund zehn Tage. Für einen einzelnen Anwendungsfall werden hier ebensowenig die Kosten ausschlaggebend sein, jedoch sind die Laufzeiten mit Jev erheblich geringer. Ähnlich ist es bei Aufgaben, die in Echtzeit laufen müssen, etwa bei der Weiterleitung eines Anrufs oder bei einer Prüfung, die jede einzelne Nachricht in einem Chatverlauf beurteilen muss. In solchen Fällen macht der Unterschied solche Aufgaben tatsächlich möglich, die bisher schon allein aus Zeitgründen nicht abbildbar gewesen wären.

Entscheiden und Formulieren werden getrennt. Der wichtigste Punkt ist aber architektonisch. Jev zwingt Entwickler dazu, einen Ablauf so zu zerlegen, wie er ohnehin zerlegt werden sollte: Das Modell trifft eng umrissene Urteile über unstrukturierte Inhalte, der Code rechnet, vergleicht und schreibt, und wo tatsächlich Text entstehen muss, kann ein Sprachmodell zuständig bleiben. Legt man die Beispiele aus den n8n-Beiträgen daneben, wird die Aufteilung konkret. Bei der Vorqualifizierung eingehender Anfragen passt Jev gut zur Zuordnung, zur Dringlichkeit und zur Frage, ob ein Termin genannt wird, nicht aber zum Herausziehen von Firmenname und Ansprechpartner, denn Jev erzeugt keine Werte, trifft nur Auswahlen. Die Jev-Dokumentation empfiehlt dafür, Kandidaten per Mustererkennung oder mit einem Sprachmodell zu sammeln und Jev den richtigen auswählen zu lassen. Bei den Lieferantenbelegen kann Jev den Lieferanten aus den Stammdaten zuordnen, das Prüfen von Beträgen und Positionen bleibt Sache des Codes. Im Wochenbericht-Ablauf aus Teil 2 ließe sich die einmalige Spaltenzuordnung als eine Auswahl pro Zielfeld über die vorhandenen Spaltenüberschriften stellen, den Wochenbericht selbst schriebe Jev dagegen nicht, sondern weiterhin ein Sprachmodell.

Wo Jev ausdrücklich schwach ist

Schön ist, wie offen der Hersteller die Grenzen seines Modells dokumentiert. Für die aktuelle Version 1.13 führt er eine eigene Liste bekannter Schwachstellen. Diese liest sich wie eine Anleitung dafür, was in einem verlässlichen Automatisierungsablauf nicht in die Stufe mit KI-Modell gehört.

Jev rechnet und zählt nicht verlässlich und kann nicht sicher entscheiden, welches von zwei Daten früher liegt. Es liest Anweisungen sehr wörtlich, sodass Verneinungen, Mehrdeutigkeiten und stillschweigende Annahmen zu falschen Antworten führen können. Die Genauigkeit sinkt, je mehr für die Frage unerhebliches Material im Sachverhalt steht, womit auch hier gilt, was im Beitrag über die Qualität der Eingabe steht: Was nicht gebraucht wird, gehört nicht hinein. Texte, die gezielt versuchen, das Modell zu lenken, können die Antwort verschieben. Bei einem Ablauf, der Mails von außen verarbeitet, ist dieses Risiko nicht theoretisch. Text kann mit Jev überhaupt nicht erzeugt werden.

Die Gegenmaßnahme ist in allen Fällen gleich: Was sich exakt berechnen lässt, muss in den Code, eine Frage, die mehrere gewünschte Urteile enthält, wird in mehrere Fragen zerlegt, und dem Modell wird nur das mitgegeben, was es für die konkrete Frage braucht. Wer seine Abläufe schon heute so baut, verliert durch diese Schwächen wenig.

Was vor einem Einsatz geklärt sein muss

Die Sprache. Jev ist vor allem auf Englisch trainiert, und dort ist es nach Herstellerangabe am genauesten. Andere Sprachen werden verarbeitet, aber „nicht gleich gut“. Für deutsche Mails, deutsche Belege und deutsche Fachbegriffe muss sich also erst noch zeigen, wie gut die Antworten sind und ob die Konfidenz auch hier noch kalibriert ist. Das lässt sich nur mit eigenen Daten beantworten.

Betrieb und Datenschutz. Jev gibt es ausschließlich als Dienst des Herstellers. Offene Modellgewichte oder einen Eigenbetrieb, wie ihn Teil 2 mit einem lokalen Modell aufgezeigt hat, ist nicht möglich. Die Dokumentation nennt keinen Verarbeitungsort - Datenhoheit also unklar. Der Auftragsverarbeitungsvertrag stützt sich auf die EU-Standardvertragsklauseln, Anfragen werden nach Angabe des Herstellers nicht zum Training verwendet, und eine Verarbeitung ohne jede Speicherung gibt es nur für Unternehmenskunden. Wo personenbezogene Daten durch den Ablauf fließen, ist deshalb vor dem Einsatz die übliche Prüfung nötig, einschließlich der Übermittlung in ein Drittland. Bei Gesundheitsdaten in Praxen oder Mandantendaten in Kanzleien würde ich derzeit darauf verzichten. Wie schon bei n8n gilt: „DSGVO-konform“ ist eine Eigenschaft der eigenen Verarbeitung, nicht des Produkts.

Die Reife. Jev wurde am 15. September vorgestellt und ist seit dem 20. September ohne Warteliste öffentlich zugänglich (allerdings zwischenzeitlich unter Verweis auf die Servicequalität schon wieder gesperrt). Das ist eine sehr kurze Zeit, um ein Modell in der Praxis zu beurteilen, und die Nutzungsgrenzen können sich laut Dokumentation ohne Ankündigung ändern. Wer Schwellen für die Konfidenz auf eine bestimmte Modellversion abgestimmt hat, sollte genau diese Version fest angeben, wie im Beispiel oben, und nicht den Alias jev-latest, denn der wandert mit jeder neuen Version mit, und die Antworten können sich dann ändern, ohne dass etwas auf der Nutzerseite geändert wurde.

Die Messwerte. Die Vergleichszahlen stammen aus den eigenen Tests des Herstellers, der selbst schreibt, sie lägen „am oberen Ende“ dessen, was in der Praxis zu erwarten ist. Als Maßstab dienten dabei die Antworten der großen Modelle von OpenAI und Anthropic. Gemessen wurde also, wie gut Jev mit diesen übereinstimmt, nicht, wie oft es tatsächlich richtig liegt. Entscheidend ist in der Realität ohnehin nicht der Preis pro Token, sondern der Preis pro richtig erledigtem Fall. Wenn der günstige Weg mehr Fälle an einen Menschen weitergibt, schrumpft die Ersparnis entsprechend.

Die Anbindung an n8n. Einen offiziellen Baustein gibt es nicht. Innerhalb weniger Tage sind auf GitHub mehrere Community-Bausteine verschiedener Autoren entstanden. Jeder davon ist fremder Code, der in der eigenen n8n-Instanz läuft und den API-Schlüssel zu sehen bekommt - diese sind also bis auf weiteres mit Vorsicht zu genießen. Für einen Versuch reicht der gewöhnliche HTTP-Request-Baustein, denn die Schnittstelle besteht aus einem einzigen, gut dokumentierten Endpunkt. Es lohnt sich außerdem, den Entscheidungsschritt als eigenen Teilablauf mit einer festen Schnittstelle zu bauen, also mit dem Sachverhalt als Eingabe und der gewählten Option inkl. Konfidenz als Ausgabe. In diesem Fall bleibt das Modell austauschbar, und wenn Jev die Erwartungen nicht erfüllt, lässt sich der gleiche Schritt mit einem Sprachmodell und strukturierter Ausgabe besetzen, ohne den Rest des Ablaufs ändern zu müssen.

Wie ein sinnvoller erster Versuch aussieht

Ein fairer Test braucht einen bestehenden Entscheidungsschritt und gute Vorbereitung. Vorhanden sein sollte eine gewisse Anzahl historischer Fälle (idealerweise 100 bis 200 für eine groß genuge Menge um auch Ausreißer zu dämpfen), bei denen die richtige Antwort bekannt ist, zum Beispiel bereits zugeordnete Anfragen oder bereinigte Stammdaten. Diese Fälle sollten möglichst solche ohne Personenbezug sein. Die Beispiele werden durch Jev und durch das bisher genutzte Sprachmodell geschickt und im Anschluss in drei Werten verglichen: Wie viele Fälle oberhalb der gewählten Schwelle automatisch erledigt werden würden, wie viele davon falsch wären und was der erledigte Fall insgesamt kostet. Liegt die Fehlerquote oberhalb der Schwelle bei Jev nicht deutlich unter der des bisherigen Wegs, oder ist der automatisch erledigte Anteil deutlich kleiner, ist die Frage für diesen Anwendungsfall beantwortet.

Wer ohnehin nur wenige Dutzend Entscheidungen am Tag trifft und mit dem bisherigen Sprachmodell zufrieden ist, muss sich bisher nicht auf Usmtellung einstellen. Der Nutzen von Jev beginnt dort, wo sehr viele Entscheidungen anfallen oder wo es auf Geschwindigkeit ankomm. Außerdem werden Prüfungen via Konfidenz einfacher, bei denen es bisher keine verlässliche Grundlage gab, um sichere Fälle von unsicheren zu trennen.

Fazit

Jev ist weniger als Produkt interessant denn als Bestätigung eines grundlegenden Architektur- und Prozessprinzips. Entscheidungen in einem automatisierten Ablauf sollten einen geschlossenen Antwortraum haben und profitieren stark von einer Aussage darüber, wie sicher sie sind. Reines Rechnen gehört in Code, und Text sollte nur dort entstehen, wo tatsächlich Text benötigt wird. Dieses Prinzip lässt sich heute schon mit n8n und jedem gängigen Sprachmodell umsetzen. Jev macht den Entscheidungsschritt schneller, günstiger und ehrlicher in Bezug auf die eigene Unsicherheit, insofern sich die Herstellerangaben auch mit deutschen Daten und außerhalb der herstellereigenen Tests bestätigen.

Ein Benchmark mit einer typischen Automatisierung werde ich demnächst umsetzen, um hier ein eigenes Bild zu gewinnen, und Anwendungsfälle aus meinem eigenen Umfeld zu prüfen.

Links

• TypeSafe AI: https://typesafe.ai/
• Ankündigung von Jev und System One: https://typesafe.ai/blog/introducing-system-one-models-and-jev
• Dokumentation: https://docs.typesafe.ai/
• Bekannte Schwächen von Jev 1.13: https://docs.typesafe.ai/model-jaggedness/jev-1.13
• Modelle, Preise und Nutzungsgrenzen: https://docs.typesafe.ai/models
• Teil 1 zu n8n: n8n: Eine (KI-)Automatisierungs-Plattform statt Infrastruktur im Eigenbau
• Teil 2 zu n8n: Vom Export zum Wochenbericht: ein n8n-Ablauf im Detail