
Modellzulassung erfordert einen ungelösten Status
Eine Entscheidung über die Zulassung eines KI-Modells muss darlegen, welche Nachweise es dem Artefakt erlauben, fortzuschreiten. Wenn ein Ladevorgang kein blockiertes Ereignis erzeugt, eine statische Prüfung jedoch weiterhin ein gefährliches Global identifiziert, komprimiert eine Genehmigung zwei unterschiedliche Befunde zu einer einzigen beruhigenden Antwort. Ich möchte, dass der ungelöste Befund die Entscheidung überdauert – mit einer klaren Darstellung dessen, was noch nachzuweisen bleibt.
Wir haben Crucible, unsere lokale Demo einer Model Vetting Firewall, um diese Unterscheidung herum aufgebaut. Sie verwendet synthetische Artefakte, darunter eine Datei, die ein Signatur-Scanner nicht meldet, deren Ladevorgang jedoch eine Datenbankoperation versucht, sowie eine weitere mit einem bedingten Zweig, der nicht ausgeführt wird. Der erste Fall veranschaulicht, warum ein beobachteter Versuch wichtig ist. Der zweite Fall legt das schwierigere Designproblem offen: zu entscheiden, was zu tun ist, wenn die verfügbaren Prüfungen uneins sind, ohne so zu tun, als sei die Unstimmigkeit beigelegt.
Die Nachweise verändern die Entscheidung
Im synthetischen Datenbankbeispiel meldet PickleScan das Artefakt nicht. Während des Ladens zeichnet ein konfigurierter CPython-Audit-Hook eine versuchte SQLite-Datenbankoperation auf und blockiert sie. Die lokale Pipeline gibt QUARANTINE zurück und stellt keine Signatur aus. Die Datenbankoperation war nicht erfolgreich; der nützliche Nachweis ist der versuchte Effekt und dessen aufgezeichnete Blockierung.
Das verleiht der Zulassungsentscheidung eine Begründung, die das saubere Scanner-Ergebnis nicht liefern kann. Ein Team kann auf die verbotene Operation verweisen, anstatt vom Label des Scanners zu verlangen, jede Frage zum Ladevorgang zu beantworten. Der Scanner bleibt als Vergleich nützlich, aber das Fehlen einer Meldung hebt einen beobachteten blockierten Versuch nicht auf.

Ich bevorzuge diese Trennung, weil sie die Entscheidung überprüfbar macht. Ein Prüfer sollte in der Lage sein, die Beziehung zwischen einem Befund und einem Ergebnis nachzuvollziehen. „Der konfigurierte Hook hat diese versuchte Datenbankoperation blockiert“ ist eine eingegrenzte Aussage. Sie benennt den Nachweis, den Mechanismus und den Grund für das lokale Urteil. Ein pauschales Sicherheitslabel würde diese Beziehungen verschleiern.
Beobachtung schafft auch ihre eigene Vertrauensgrenze. Hier versucht der Worker das Laden in einem Python-Subprozess und überwacht konfigurierte Audit-Ereignisse. Das ist Demo-Instrumentierung mit Prozesstrennung und keine Kapselung auf Betriebssystem- oder Containerebene. Ein Produktionsdesign müsste festlegen, wie der Beobachtungs-Worker selbst isoliert wird, bevor man ihm nicht vertrauenswürdige Artefakte anvertraut. Das Hinzufügen von Verhaltensnachweisen entbindet nicht von der Pflicht, die Umgebung zu prüfen, die sie erfasst.
Ein unauffälliger Ladevorgang hinterlässt eine schwierigere Frage
Das bedingte synthetische Fixture führt zu einem anderen Ergebnis. Die statische Prüfung findet builtins.eval, ein Global auf der konfigurierten Gefahrenliste der Demo. Der beobachtete Ladevorgang verzeichnet kein blockiertes gefährliches Ereignis, da der bedingte Zweig in dieser Umgebung nicht durchlaufen wird. Die Pipeline leitet das Artefakt ohne Signatur an REVIEW weiter. Über diesen Weg wurde keine menschliche Untersuchung abgeschlossen.

Es gibt drei vertretbare Reaktionen, und jede erfordert einen anderen Einsatz. Eine Genehmigung akzeptiert die Unsicherheit. Eine Ablehnung vermeidet die Nutzung dieses Artefakts, kann aber etwas verwerfen, das eine gezieltere Untersuchung erklären könnte. Eine weitere Überprüfung verzögert die Entscheidung und erfordert, dass jemand definiert, welche zusätzlichen Nachweise sie ändern könnten.
In diesem Fall ziehe ich eine Überprüfung vor, da die Unsicherheit spezifisch ist. Es gibt ein identifiziertes statisches Bedenken und eine identifizierte Lücke in der Beobachtung. Der unauffällige Lauf erklärt nicht, warum das gefährliche Global vorhanden ist oder was geschieht, wenn der Zweig erreicht wird. Eine Genehmigung würde bedeuten, diese Lücke zu akzeptieren. Eine sofortige Ablehnung könnte eine vernünftige Richtlinie der Organisation sein, wäre jedoch die Entscheidung, das Artefakt aufgrund ungelöster statischer Nachweise auszuschließen, und kein Beweis dafür, dass eine verbotene Auswirkung eingetreten ist.
Diese Unterscheidung ist wichtig, wenn ein Team seine Zulassungsrichtlinie verfasst. Das Ausbleiben einer beobachteten Auswirkung sollte nicht stillschweigend zu dem Befund werden, dass die Auswirkung nicht eintreten kann. Ebenso sollte ein Verdacht nicht stillschweigend zum Beweis eines erfolgreichen Angriffs werden. REVIEW bietet einen Ort, um beide Tatsachen festzuhalten, während die Organisation wählt, wie viel Unsicherheit sie akzeptieren kann.
REVIEW benötigt ein Ausstiegskriterium
Ein Überprüfungsstatus allein kann zu einem kostspieligen Wartestand werden. Er verdient seinen Platz nur, wenn das Protokoll die ungelöste Frage und die nächste Entscheidung erklärt, die jemand treffen muss. In diesem Beispiel betrifft die Frage das statische Global und den ungenutzten Zweig. Die Wiederholung desselben unauffälligen Ladevorgangs, ohne den Untersuchungsgegenstand zu ändern, würde eine weitere Beobachtung hinzufügen, ohne diese Frage zu beantworten.
In einem hypothetischen Unternehmensprozess könnte ein Team den Zweig inspizieren, eine vertrauenswürdige Erklärung vom Lieferanten des Artefakts einholen oder ein Ersatzartefakt mit einem besser prüfbaren Ladepfad wählen. Das sind vorgeschlagene Reaktionen, keine Arbeitsabläufe, die diese Demo abschließt. Jede hat ihren Preis: Eine tiefere Inspektion erfordert Fachwissen, Lieferantennachweise erfordern eine eigene Validierung, und ein Austausch opfert möglicherweise benötigte Funktionen. Die Wahl hängt davon ab, welche Nachweise das Team erhalten kann und welche Unsicherheit seine Richtlinie zulässt.
Ich möchte, dass diese Wahl explizit ist. Wenn keine verfügbare Untersuchung das Bedenken innerhalb der Rahmenbedingungen des Teams ausräumen kann, kann die Ablehnung des Artefakts das angemessene Ende der Überprüfung sein. REVIEW sollte nicht versprechen, dass jede Datei schließlich eine Genehmigung erhält. Sein Zweck besteht darin, zu verhindern, dass eine ungelöste Frage in einem Urteil verschwindet, und die letztendliche Entscheidung an einer erklärten Richtlinie messbar zu machen.
Dieselbe Disziplin gilt für KI-Erklärungen. In der Demo kann eine kombinierte Analysten- und Challenger-Empfehlung Vorsicht walten lassen und ein Basis-ALLOW-Ergebnis auf REVIEW verschieben; sie kann QUARANTINE nicht aufheben. Die aufgezeichnete Präsentation nutzt zwischengespeicherte Codex-Empfehlungen neben frisch konfigurierten Prüfungen. Ein synthetischer Referenzdatensatz verdeutlicht die Gefahr, Narrative als Autorität zu behandeln: Seine Empfehlung rät zur Signierung und Freigabe, während das endgültige strukturierte Ergebnis REVIEW lautet und keine Signatur ausgestellt wird.
Ein Zulassungsanwender sollte daher das strukturierte Urteil, den Gate-Grund und das tatsächliche Signaturfeld lesen. Hilfreiche Prosa kann eine Entscheidung erklären, darf aber nicht zu einer zweiten, widersprüchlichen Erlaubnis werden, ein Artefakt weiterzuleiten. Ein Überprüfungsprozess, der dem Empfehlungssatz mehr vertraut als dem endgültigen Gate, hat die Unterscheidung verloren, die er eigentlich bewahren sollte.
Auch die Genehmigung hat eine Grenze
Das synthetische Wörterbuch mit sauberen Gewichten erhält ALLOW und eine Signatur über seinen Modellnamen, den Artefakt-Hash und die Inventar-Nutzlast unter Verwendung eines lokalen Entwicklungsschlüssels. Die Herkunft seiner Trainingsdaten und der Fine-Tuning-Verlauf bleiben UNKNOWN. Nur ALLOW erhält diese Signatur; REVIEW und QUARANTINE tun dies nicht.
Dies ist für den Ausstieg aus der Überprüfung ebenso wichtig wie für den sauberen Pfad. Die Beilegung eines Bedenkens beim Laden würde für sich genommen keinen Trainingsverlauf begründen. Eine Signatur kann die angegebene lokale Nutzlast relativ zu ihrem Schlüssel authentifizieren, während eine vorgelagerte Frage unbeantwortet bleibt. Ein Team sollte separat prüfen, ob die Zulassungsnachweise für die Ladeentscheidung ausreichen und ob die fehlende Herkunft für den beabsichtigten Einsatz akzeptabel ist. Eine genehmigte Prüfung sollte keine Frage klären, die sie nie untersucht hat.
Der Crucible-Leitfaden zeigt diese lokalen Beispiele und deren Nachweise. Registry-Integration, unternehmensweite Zulassungsdurchsetzung und Produktions-Signaturverwaltung bleiben Aufgaben jenseits dieser Demo. Ihr Wert liegt in der Entscheidungsgrenze, die sie sichtbar macht, und nicht in dem Anspruch, dass die lokale Implementierung alle Kontrollen liefert, die ein Unternehmen benötigen würde.
Hier ist das Video des Gründers, das die lokale synthetische Modellprüfung in der Demo zeigt.
Für ein Plattform-Team, das ein Zulassungsdesign evaluiert, würde ich mit dem Fall beginnen, dessen Nachweise nicht nahtlos zusammenpassen. Fragen Sie, was den ungelösten Befund sichtbar hält, wer entscheidet, ob eine weitere Untersuchung ihren Preis wert ist, und welche Nachweise das Ergebnis ändern können. Ein sauberer Pfad ist leicht zu beschreiben. Der ungelöste Pfad offenbart, ob das System Unsicherheit lange genug bewahrt, damit eine verantwortungsvolle Entscheidung getroffen werden kann.




