Am 25. September 2026 kündigte TypeSafe AI Jev an, das erste Modell in dem, was das Unternehmen die Kategorie „System One“ nennt: kein Chatbot und nicht einfach ein größeres Sprachmodell, sondern das, was das Unternehmen als Entscheidungsmodell beschreibt — etwas, das gebaut wurde, um eine begrenzte Frage mit einer typisierten, kalibrierten Antwort statt einem Absatz Fließtext zu beantworten. Die Ankündigung ist dicht mit konkreten Zahlen, daher geht dieser Beitrag sie genau so durch, wie sie behauptet werden, markiert klar, was wir überprüfen konnten und was nicht, und schaut sich an, warum die zugrunde liegende Idee — entscheiden statt erzeugen — insbesondere für Sicherheitssoftware ernst zu nehmen ist.
Was TypeSafe tatsächlich angekündigt hat
TypeSafe AI wurde von Diogo Almeida gegründet, der in der Ankündigung schreibt: „Bei OpenAI habe ich mitgeholfen, die Methoden zu entwickeln, die Sprachmodelle darin nützlich gemacht haben, Anweisungen zu befolgen und mit Menschen zu sprechen.“ Jev, vom Unternehmen als sein „erstes öffentliches Modell“ bezeichnet, wird als eine völlig andere Aufgabe angepriesen: die Erzeugung dessen, was TypeSafe typsichere strukturierte Werte mit kalibrierten Wahrscheinlichkeiten und Konfidenzwerten nennt, erzeugt durch das, was das Unternehmen einen parallelen Sampler statt der üblichen Token-für-Token-Dekodierung nennt, trainiert mit einer Methode, die das Unternehmen Reinforcement Learning for Calibrated Decisions, kurz RLCD, nennt.
- TypeSafe berichtet eine End-to-End-Antwortzeit von „70 ms bis 500 ms“, gegenüber „3 bis 329 Sekunden“, die es für die Spitzen-Sprachmodelle gemessen haben will, mit denen Jev verglichen wurde.
- TypeSafe bepreist Input-Tokens mit „0,042 $ / MTok“, Output-Tokens werden als kostenlos aufgeführt.
- In seinen eigenen Workflow-Auswertungen berichtet TypeSafe, Jev laufe „193,6-mal schneller, 444,6-mal günstiger“ als die Richtlinien, gegen die es gemessen wurde.
- TypeSafe beschreibt einen Typfehler in Jevs Ausgabe, in den eigenen Worten, als „mathematisch unmöglich“.
- Jev befindet sich im Early Access; TypeSafe sagt, es hole Entwicklerinnen und Entwickler „so schnell wie möglich von der Warteliste“.
Erzeugen versus Entscheiden
Ein großer Teil dessen, was als „KI im produktiven Einsatz“ bezeichnet wird, ist im Grunde gar keine Schreibaufgabe. Eine Verbindung zulassen oder blockieren. Ein Ticket eskalieren oder schließen. Eine Transaktion markieren oder freigeben. Eine Nachricht in die eine oder andere Warteschlange leiten. Die gewünschte Ausgabe ist keine Prosa, sondern ein Label aus einer kurzen, festen Liste, manchmal mit einem angehängten Wert. Eine solche Frage durch ein Modell laufen zu lassen, das für flüssige Absätze gebaut wurde, passt nicht zusammen: Es kommt ein JSON-Blob zurück, den man parsen und auf Gültigkeit hoffen muss, und eine angegebene Konfidenz bedeutet meist wenig Konkretes, weil nichts sie gezwungen hat, die tatsächliche Fehlerrate des Modells widerzuspiegeln.
Zwei Behauptungen lohnt es sich hier zu trennen, denn sie sind nicht dasselbe: typisiert und kalibriert. Eine typisierte Ausgabe schränkt die Form der Antwort ein — eine „choice“-Frage liefert eine der Optionen aus der Liste zurück, ein „score“ liefert eine Zahl innerhalb eines festgelegten Bereichs, nie einen beliebigen Satz oder ein erfundenes Feld. Kalibrierung ist eine viel ältere und völlig eigenständige Idee. Sie ist eine statistische Eigenschaft, keine stilistische: Sie bedeutet, dass, wenn das System eine Wahrscheinlichkeit von 0,62 angibt, es über viele ähnliche Vorhersagen hinweg auch tatsächlich so oft richtig liegt — sodass ein nachgelagertes Programm diesen Wert wirklich als Schwellenwert nutzen kann, statt ihn als Dekoration zu behandeln.
TypeSafes eigene Namensgebung entlehnt ihr Vokabular eher der Psychologie als der Statistik. Daniel Kahneman, der 2002 den Alfred-Nobel-Gedächtnispreis für Wirtschaftswissenschaften erhielt, „für die Integration von Erkenntnissen aus der psychologischen Forschung in die Wirtschaftswissenschaften, insbesondere zu menschlichem Urteilen und Entscheiden unter Unsicherheit“, machte die Begriffe in Schnelles Denken, langsames Denken populär: „System 1“ ist „schnell, automatisch, häufig, emotional, stereotyp, unbewusst“, während „System 2“ „langsam, anstrengend, selten, logisch, rechnend, bewusst“ ist. Die Metapher ist eingängig, beschreibt aber menschliche Kognition, keine Garantie für ein Stück Software. Ein Modell kann so schnell sein, wie System 1 schnell ist, ohne dass seine angegebene Konfidenz überhaupt etwas bedeutet — Kalibrierung muss erarbeitet und gemessen werden, nicht durch einen Namen suggeriert.
Was „kann nicht halluzinieren“ bedeuten kann — und was nicht
TypeSafes Behauptung, ein Typfehler sei „mathematisch unmöglich“, beschreibt eingeschränkte Dekodierung (constrained decoding), eine Technik, die anderswo bereits existiert. OpenAIs eigener Leitfaden zu Structured Outputs gibt eine ähnliche Garantie: Die Funktion, so heißt es dort, „stellt sicher, dass das Modell immer Antworten erzeugt, die Ihrem angegebenen JSON-Schema entsprechen, sodass Sie sich keine Sorgen machen müssen, dass das Modell einen erforderlichen Schlüssel auslässt oder einen ungültigen Enum-Wert halluziniert.“ Diese Garantie ist real und nützlich. Sie ist auch enger, als sie klingt: Sie schränkt die Form der Antwort ein, nicht, ob die Antwort richtig ist. Eine „choice“-Frage mit drei Optionen liefert immer eine der drei zurück — auch, wenn das Modell die Eingabe falsch eingeschätzt hat, eine selbstbewusste, gültig typisierte, aber falsche Antwort.
Kalibrierung ist der Teil, der überprüft werden muss, nicht behauptet werden darf. Das Standardwerkzeug ist ein Reliability-Diagramm: Vorhersagen werden nach angegebener Konfidenz in Klassen eingeteilt, und für jede Klasse wird aufgetragen, wie oft diese Vorhersagen tatsächlich richtig waren; die Lücke zwischen der Diagonalen und der beobachteten Linie wird meist als erwarteter Kalibrierungsfehler zusammengefasst. Das ist keine neue Frage für maschinelles Lernen — Guo u. a.s Arbeit von 2017 „On Calibration of Modern Neural Networks“ stellte fest, dass „moderne neuronale Netze … standardmäßig schlecht kalibriert“ sind, und dass eine einfache Korrektur mit nur einem Parameter namens Temperature Scaling „überraschend wirksam“ war, um das zu beheben. Die Lehre reicht über diese eine Arbeit hinaus: Kalibrierung ist keine Eigenschaft, die ein Modell einfach über sich selbst verkünden darf. Es ist etwas, das man an eigenen, gelabelten Daten prüft, denn sie verschlechtert sich tendenziell genau dort, wo man sie am dringendsten braucht — bei Eingaben, die nichts mit dem gemein haben, worauf das Modell abgestimmt wurde.
Ein minimales Test-Grundgerüst (Vorlage)
Bevor eine echte Entscheidung durch irgendein Entscheidungsmodell geleitet wird, Jev oder ein anderes, zählen drei Fragen mehr als jede Herstellerzahl: Lässt sich die typisierte Antwort jedes einzelne Mal gegen Ihr Schema parsen, entspricht eine angegebene Konfidenz der tatsächlichen Trefferquote auf einer gelabelten Stichprobe Ihrer eigenen Daten, und übersteht diese Kalibrierung Eingaben, die sich von allem unterscheiden, was das Modell bereits gesehen hat. Die folgende Skizze ist eine Vorlage, gebaut um die Anfrageform, die in TypeSafes eigener Quickstart-Dokumentation gezeigt wird. Sie behauptet nichts darüber, was ein Lauf gegen Jev zeigen würde — wir haben sie nicht ausgeführt, und das ist illustrativer Pseudocode, kein Bericht.
# Illustrative pseudo-code. Mirrors the request shape shown in TypeSafe's own
# quickstart docs (POST /v1/systemone with state, model, and typed questions).
# Not run against Jev or any live API; no results are claimed here.
import requests
def ask(state: str, question_id: str, question: dict) -> dict:
resp = requests.post(
"https://api.typesafe.ai/v1/systemone",
headers={"Authorization": f"Bearer {API_KEY}"},
json={"state": state, "model": "jev-latest", "questions": {question_id: question}},
)
return resp.json()["answers"][question_id]
# 1. Shape check: does every response parse against the declared type, on your
# own edge cases, not just a vendor demo set?
# 2. Calibration check: bucket the stated confidence and compare it to the
# true label rate, on data the model has never seen.
buckets = {i: {"n": 0, "correct": 0} for i in range(10)}
for state, true_label in labeled_sample: # your own traffic, labeled by hand
answer = ask(state, "decision", {"type": "noul", "instructions": "Should this be allowed?"})
bucket = min(int(answer["noul"] * 10), 9)
buckets[bucket]["n"] += 1
buckets[bucket]["correct"] += int(round(answer["noul"]) == true_label)
for b, s in buckets.items():
if s["n"]:
stated = (b + 0.5) / 10
observed = s["correct"] / s["n"]
print(f"stated~{stated:.2f} observed={observed:.2f} n={s['n']}") # the gap here is your calibration error- Ob die typisierte Antwort immer parsebar ist, bei Eingaben, die Ihr eigenes System erzeugt, nicht nur beim Demo-Set eines Anbieters.
- Ob eine angegebene 0,9 auf Ihrem eigenen gelabelten Traffic tatsächlich neun von zehn Mal richtig liegt, nicht auf dem Eval-Set von jemand anderem.
- Ob diese Kalibrierung bei Eingaben hält, die nichts von dem ähneln, was das Modell zuvor gesehen hat: eine neue App, ein neues Protokoll, ein Absender, der genau diese Ankündigung ebenfalls gelesen hat.
- Was der Aufrufer bei einem Timeout oder Ausfall tut, denn ein Entscheidungssystem braucht einen sicheren Standardwert, wenn das Entscheidungsmodell nicht erreichbar ist.
Warum das für Sicherheitswerkzeuge zählt
Eine Firewall, ein Spamfilter, eine Betrugsprüfung, eine Triage-Warteschlange: Jedes davon ist ein Entscheidungssystem, das immer wieder dieselbe Art von Frage beantwortet — bei dieser Eingabe, zulassen oder blockieren, mit welcher Konfidenz, und wo die Schwelle liegt. TypeSafes eigene Auswertungsseite entnimmt ihre Beispiele genau diesem Bereich: zu beurteilen, ob ein Sicherheitsalarm geschlossen, an eine Person eskaliert oder sofort eingedämmt werden soll, ist eine Triage-Entscheidung, keine Schreibaufgabe, und genau diese Art von Entscheidung trifft ein Sicherheitswerkzeug ständig, in einem Umfang, den kein Analyst von Hand durchsehen könnte.
| Antwort eines generativen LLM | Typisierte Entscheidung (im Stil von Jev) | |
|---|---|---|
| Ausgabe | Ein Absatz, der erklärt, die Verbindung zu einer unbekannten Adresse über einen ungewöhnlichen Port „könnte eine Prüfung wert sein“ | { allow: false, confidence: 0.81 } |
| Parsen | Regex, oder ein zweiter Modellaufruf, um eine Aktion aus dem Fließtext zu extrahieren | Garantiert passend zum deklarierten Schema |
| Schwellenwert | Keine numerische Konfidenz, die man gegen eine Richtlinie vergleichen könnte | Ein Konfidenzwert, den der Aufrufer direkt als Schwelle nutzen kann |
| Fehlerfall | Flüssig, plausibel klingend, und manchmal schlicht falsch | Falsch mit einer angehängten Zahl, was eine Kalibrierungsprüfung im Schnitt zumindest auffangen kann |
Der Kompromiss beim Datenschutz, ehrlich betrachtet
Jev ist, so wie TypeSafe es beschreibt, eine gehostete API: Eine Anfrage trägt „state“ — also welche Daten auch immer die Frage betreffen — über das Internet zu TypeSafes Servern. Für die Beispiele zu Sicherheitsvorfällen und Triage, die TypeSafe selbst hervorhebt, ist dieser state genau die Art von Information, die viele Menschen nicht standardmäßig einem Dritten geben möchten — welche App mit welcher Adresse spricht, wie oft, von welchem Gerät aus. Sie an irgendein Cloud-Modell zu senden, wie schnell oder günstig auch immer, bedeutet, dass diese Daten die Maschine verlassen, von der sie stammen.
FireAI, die eigene macOS-Firewall von HisnLabs, hat für genau diese Kategorie von Entscheidung, um die es in diesem Artikel geht, die entgegengesetzte Wahl getroffen. FireAI läuft auf macOS 14 oder neuer auf Apple-Silicon-Macs, für einmalig 49 €, und ist ausdrücklich kein Antivirenprogramm und kein VPN. Wenn eine App, die Sie noch nicht kennen, versucht, das Netzwerk zu erreichen, kann FireAI ein kleines Modell direkt auf dem Gerät ausführen — ein optionaler 1,5-GB-Download —, um diese Verbindung zu prüfen und Sie mit einem in einfacher Sprache angehängten Grund zu fragen; der geprüfte Datenverkehr wird niemals irgendwohin gesendet. Jede dieser KI-gestützten Entscheidungen wird zu einer sichtbaren, an die Code-Signatur der App gebundenen Regel, die Sie sehen und rückgängig machen können, neben Bedrohungslisten, die lokal angewendet werden, statt bei einem entfernten Server abgefragt zu werden.
Wir behaupten nicht, dass das On-Device-Modell von FireAI mit Jev oder irgendeinem anderen System-1-Modell in reiner Korrektheit, Geschwindigkeit oder Preis mithält — wir haben diesen Vergleich nicht durchgeführt und haben keine eigenen Auswertungen, die wir hier veröffentlichen könnten. Was diese Ankündigung stützt, ist eine Design-Richtung: dass einer Sicherheitsentscheidung mit einem kleinen, schnellen, eng begrenzten Modell, das nahe an den Daten läuft, besser gedient ist als damit, sie irgendwo anders durch einen allgemeinen Chatbot zu leiten. TypeSafe macht diesen Fall von der API-Seite aus; FireAI baut bereits von der Geräteseite aus darauf auf, und aus einem anderen Grund — weil bei einer Firewall die betreffenden Daten die Maschine gar nicht erst verlassen sollten, um beurteilt zu werden.
Offene Fragen
- Unabhängige Auswertungen: Noch hat keine externe Stelle eine Nachbildung der Geschwindigkeits- oder Kostenfaktoren aus TypeSafes Ankündigung veröffentlicht, auf Daten, die nicht TypeSafe selbst ausgewählt hat.
- Kalibrierung bei Verteilungsverschiebung — genau das Szenario, um das es in der Arbeit von Guo u. a. geht, und das Szenario, das am meisten zählt gegen einen Gegner, der sich anpasst, sobald eine Verteidigungsmethode öffentlich ist.
- Ob die Preisgestaltung bei echtem Produktionsvolumen hält, und ob die angegebene Latenz unter dauerhafter Last hält, statt nur bei einer einzelnen vorgeführten Anfrage.
- Wie sich das Modell bei feindlichen oder wirklich mehrdeutigen Eingaben verhält, wo eine selbstbewusste, typisierte Antwort weniger ehrlich sein kann als eine Antwort, die „unklar“ sagt.
- Wann der Early Access über die Warteliste hinaus geöffnet wird, für wen, und unter welchen Bedingungen für die als „state“ gesendeten Daten.
Vorerst ist Jev eine Reihe von Behauptungen eines Teams mit echten Referenzen und noch ohne externe Überprüfung. Die Kategorie, die es zu benennen versucht — Entscheidungsmodelle statt Generierungsmodelle —, weist auf eine reale Lücke hin, wie Sicherheitssoftware bisher dazu gebracht wurde, KI zu nutzen. Ob Jev selbst einer unabhängigen Prüfung standhält oder nicht, es ist eine nützliche Erinnerung daran, dass die interessante Frage für eine Firewall, einen Betrugsfilter oder eine Triage-Warteschlange nie „kann es einen überzeugenden Satz schreiben“ war, sondern „kann es eine Entscheidung treffen, für die es geradestehen kann, schnell genug, um zu zählen“. Genau diese Frage stellen wir uns über das On-Device-Modell in FireAI jedes Mal, wenn wir es ändern — und deshalb bleibt die Antwort bei uns auf dem Gerät, statt zu einer Anfrage an die API von jemand anderem zu werden.
Wo FireAI und HisnLabs ins Spiel kommen
We have not tested Jev and make no claim it works as described or that FireAI matches it in any way — but the idea that a security decision deserves a small, bounded, fast model instead of a paragraph from a chatbot is one we built FireAI around a year before TypeSafe wrote a blog post about it.
FireAI ist das eigene Produkt von HisnLabs: eine KI-Firewall für den Mac, die direkt auf dem Gerät läuft. Sie zeigt jede Verbindung Ihrer Apps in verständlicher Sprache und lässt Sie entscheiden, was Ihren Mac verlässt — die KI arbeitet lokal, Ihr Datenverkehr wird also nie an uns oder irgendjemand anderen gesendet. Das Sicherheitsforschungsteam von HisnLabs sorgt dafür, dass diese Entscheidungen verlässlich bleiben: Es katalogisiert, welche Domains gewöhnliche Telemetrie und welche ein echter Dienst sind, verfolgt Land und Netzwerk hinter einer Verbindung und trainiert das lokale Modell (die Autopilot-Funktion) mit echten Verkehrsmustern — ohne dass irgendetwas davon Ihren Mac verlässt.
Die technischen Entscheidungen dahinter können Sie nachlesen — oder FireAI 17 Tage lang ausprobieren — unter FireAI, von HisnLabs.