Die KI-Anfrage eines Mitarbeiters
Der Code führt die Aktion an.
Entdecken Sie diesen Artikel 6 Kapitel
Die nächste Grenze der Workforce-KI-Sicherheit besteht darin, bessere Entscheidungen genau im Moment der KI-Nutzung durch Mitarbeiter zu treffen. Ich möchte Kontrollen, die die Anfrage verstehen, die richtige Richtlinie anwenden und den Arbeitsfluss erhalten.
Deshalb hat Jev, eingeführt von TypeSafe AI, meine Aufmerksamkeit erregt. Sein Ansatz für schnelle, strukturierte Entscheidungen eröffnet eine Chance: mehr kontextuelles Urteilsvermögen in das kurze Zeitfenster zwischen der Handlung eines Mitarbeiters und deren Folgen zu bringen.
Warum Jev?
Jev interessiert mich, weil es natürlichsprachliches Verständnis mit einem für Entscheidungen trainierten Modell kombiniert. TypeSafe beschreibt parallele typisierte Ausgaben, ohne eine Antwort Token für Token zu generieren. Die mit jeder Anfrage gelieferten Fragen definieren die zu treffenden Urteile, und die Ergebnisse liefern strukturierte Signale, die Software nutzen kann.
Das ist ein nützliches Design für häufige, begrenzte Richtlinienprüfungen. Die architektonische Chance besteht darin, die Kontrolle näher an jede Mitarbeiteraktion zu bringen, mit genügend Kontext für eine sinnvolle Entscheidung und so wenig Verzögerung wie möglich, um die Nutzererfahrung zu erhalten. Es muss noch gegen Alternativen mit denselben Richtlinien getestet werden.
Wie Jev sich vergleicht
Diese Kategorien überschneiden sich: Ein Detektor kann Regeln und Modelle kombinieren, und ein Guard-Modell kann ein LLM sein. Ich würde nach der Entscheidung wählen, die jede Ebene treffen muss. Die Durchsetzung bleibt Aufgabe des Codes.
Jev-ähnliche EntscheidungsmodelleTextbasierte Urteile mit flexiblen Kriterien und typisierten Wahrscheinlichkeiten.
Jev bewertet Text anhand von anfrage-definierten Kriterien mit gemeinsamen Modellgewichten. Seine Dokumentation beschreibt typisierte Wahrscheinlichkeiten für begrenzte Urteile, ohne generierte Erklärungen. Das eignet sich für sich ändernde Richtlinienfragen. Dateiparsen, Schwärzung und Durchsetzung bleiben Aufgabe der umgebenden Software; Genauigkeit, Latenz und Schwellenwerte müssen noch auf den vorgesehenen Daten bewertet werden.
Allzweck-LLM-RichterBreites Schlussfolgern und Erklärungen, mit verfügbaren strukturierten Ausgaben.
Nützlich, wenn eine Prüfung breiteres Denken oder eine Erklärung erfordert. Unterstützte LLM-APIs bieten auch schema-konformes JSON; dieses Format ist nicht einzigartig für Jev und kann weiterhin Fehler enthalten. Messen Sie Qualität, Latenz und Kosten für das ausgewählte Modell und die Einstellungen.
Regeln und MustererkennungExplizite Bedingungen mit vorhersehbaren, überprüfbaren Ergebnissen.
Verwenden Sie exakte Regeln für Whitelists, Ziele, bekannte Formate und explizite Zugangsbedingungen. Open Policy Agent bewertet Richtlinien über bereitgestellte Daten; er leitet keine versteckten Absichten aus Fließtext selbst ab. Regeln sind innerhalb ihrer Definitionen vorhersehbar, aber sie erfassen keine Verstöße, die außerhalb dieser Definitionen liegen.
PII- und GeheimnisdetektorenErkennen sensible Bereiche und erkennbare Zugangsdaten.
Presidio findet sensible Textstellen mit Mustern, Entitätserkennungsmodellen und Validierung; Gitleaks zielt mit Regeln auf Geheimnisse ab. Ihre Ergebnisse können Schwärzungs-Workflows leiten. Ihre konfigurierte Abdeckung kann unbekannte Daten übersehen, und das Finden einer Entität entscheidet nicht allein, ob deren Weitergabe erlaubt ist.
Dedizierte Guard-ModelleSpezialisierte Sicherheits- oder Angriffserkennung innerhalb eines definierten Bereichs.
Llama Guard bewertet Inhalte anhand einer definierten Sicherheits-Taxonomie, während Prompt Guard versucht, Anweisungsüberschreibungen zu erkennen. Nützlich, wenn der Trainingsumfang zur Prüfung passt. Ihre dokumentierten Domänen- und Angriffsgrenzen sind weiterhin relevant, und ein Modellurteil allein kann nicht sicherstellen, dass eine Anfrage sicher durchgesetzt wurde.
Kontext ändert die Entscheidung
Anschauliche politische Beispiele
Gleiches Thema. Andere Absicht.
Beispiel für eine Richtlinie: Erlauben Sie Aufklärung, verbieten Sie den Diebstahl von Zertifikaten.
“Erklären Sie, warum diese E-Mail als Phishing für unsere Mitarbeiter-Awareness-Session dient.”
Hilft diese Anfrage, Zugangsdaten zu stehlen?
Nein
Allow
Die Anfrage hilft den Menschen, Phishing zu erkennen. Sie hilft nicht, Zugangsdaten zu stehlen.
Betrachten Sie eine Richtlinie, die Sicherheitsschulungen erlaubt, aber Hilfe beim Diebstahl von Zugangsdaten verbietet. „Erkläre, warum diese E-Mail Phishing ist“ und „Mache diese Zugangsdaten-Phishing-E-Mail überzeugender“ verwenden denselben Wortschatz, fordern aber sehr unterschiedliche Hilfe an. Eine kontextuelle Prüfung kann bewerten, was die Unterstützung ermöglichen würde. Dies sind synthetische Beispiele für eine Richtlinienunterscheidung, keine gemessenen Jev-Ergebnisse. TypeSafes Guardrail Cookbook zeigt, wie Klassifikation und Schweregradbewertung solche begrenzten Urteile unterstützen können.
Ein besseres Signal für Richtlinien
Eine strukturierte Verteilung bietet dem Richtliniencode mehr als ein einzelnes Label. Verschiedene Prüfungen können unterschiedliche Schwellenwerte haben, die die Folgen eines verpassten Verstoßes oder einer unnötigen Blockade widerspiegeln. Mehrdeutige Ergebnisse können eine tiefere Bewertung auslösen. Das Sicherheitsteam definiert weiterhin die Aktion; das Modell liefert ein Signal. Das macht die Kompromisse explizit und gibt Teams etwas Konkretes zur Bewertung gegenüber ihren eigenen Richtlinien.
Illustrative Daten · 12 synthetische Anfragen · Nicht Jev Messungen
Verschieben Sie die Blockschwelle
Eine Anfrage wird blockiert, wenn die geschätzte Wahrscheinlichkeit eines Richtlinienverstoßes die Schwelle erreicht oder überschreitet.
1 / 6
Legitime Anfragen blockiert
2 / 6
Verstöße unterhalb der Schwelle
5 von 12 blockierten Anfragen bei 70%.
Unterhalb der Schwelle passieren Anfragen in diesem vereinfachten Beispiel. Ein echtes System kann einen Überprüfungsschritt hinzufügen.
Überprüfen Sie die illustrativen Daten
Sechs legitime Anfragen und sechs Verstöße gegen die Richtlinien. Diese festen Werte zeigen Schwellenwert-Kompromisse, nicht die gemessene Modellleistung.
| Anfrage | Aktueller Status | p(Verstoß) | Entscheidung |
|---|---|---|---|
| L1 | Legitim | 8% | Passes |
| L2 | Legitim | 18% | Passes |
| L3 | Legitim | 31% | Passes |
| L4 | Legitim | 55% | Passes |
| L5 | Legitim | 68% | Passes |
| L6 | Legitim | 88% | Blockiert |
| V1 | Richtlinienverletzung | 46% | Passes |
| V2 | Richtlinienverletzung | 62% | Passes |
| V3 | Richtlinienverletzung | 74% | Blockiert |
| V4 | Richtlinienverletzung | 81% | Blockiert |
| V5 | Richtlinienverletzung | 92% | Blockiert |
| V6 | Richtlinienverletzung | 97% | Blockiert |
Diese Signale müssen validiert werden. Jevs separate Confidence-Eigenschaft beschreibt die Konzentration der Verteilung, nicht die Wahrscheinlichkeit, dass eine Antwort korrekt ist. Die Kalibrierung wird über Vorhersagen hinweg gemessen und kann kein einzelnes Ergebnis garantieren. TypeSafe erkennt in seinen Jev 1.13 Einschränkungen ausdrücklich an, dass adversative Inhalte Antworten beeinflussen können. Sicherheitsbewertungen müssen daher neben der Latenz auch Fehlalarme, verpasste Verstöße und Manipulationsresistenz messen.
Die Standardinnovation muss
Ich sehe die stärkste Architektur als Kombination spezialisierter Kontrollen. Deterministische Detektoren behandeln bekannte Muster und explizite Einschränkungen. Kontextuelle Modelle beantworten begrenzte Fragen zur Bedeutung. Richtliniencode wendet die Entscheidung an, und die Durchsetzung muss zuverlässig bleiben, wenn ein Modell unsicher oder nicht verfügbar ist. Jede Ebene hat eine definierte Aufgabe, und das Schutzsystem muss als Ganzes getestet werden.
Datenschutz gehört von Anfang an in diese Architektur. Eine Schutzvorrichtung darf genau die Informationen prüfen, die sie schützt. Verarbeitungsort, Zugriff, Aufbewahrung und Trainingsnutzung sind technische Anforderungen. Jedes Modell, das für diese Rolle in Betracht gezogen wird, benötigt einen sicheren Bereitstellungspfad und Datenhandhabungsvereinbarungen, die den Kundenanforderungen entsprechen. Eine schnellere Entscheidung hat nur innerhalb eines Schutzsystems Wert, dem Kunden vertrauen können.
Unsere Ausrichtung bei Aona
Bei Aona untersuchen wir diese Modellklasse für eine genaue, schnelle Klassifizierung von Schutzmaßnahmen. Jev ist ein interessantes Beispiel für diese Richtung, und unser Fokus liegt auf der Fähigkeit, die dieser Ansatz für den Schutz der KI-Nutzung von Mitarbeitern ermöglichen könnte.
ermöglichen könnte.
Quellen hinter dieser Perspektive 12 Primärquellen
- Jev, vorgestellt von TypeSafe AI
- parallele typisierte Ausgaben
- Dokumentation
- schema-eingeschränktes JSON
- Open Policy Agent
- Presidio
- Gitleaks
- Llama Guard
- Prompt Guard
- Guardrail Cookbook
- Confidence-Eigenschaft
- Jev 1.13 Einschränkungen
Die interaktiven Beispiele sind verfasste Illustrationen, nicht gemessen Jev Ausgaben. Quellen geprüft am 22. September 2026.
