L'ammissione dei modelli richiede uno stato irrisolto

Una decisione di ammissione di un modello di IA deve indicare quali prove consentono all'artefatto di procedere. Quando un caricamento non produce alcun evento bloccato ma l'ispezione statica identifica comunque un elemento globale pericoloso, un'approvazione comprime due riscontri distinti in un'unica risposta rassicurante. Voglio che il riscontro irrisolto sopravviva alla decisione, con una chiara spiegazione di ciò che resta ancora da stabilire.

Abbiamo costruito Crucible, la nostra demo locale di Model Vetting Firewall, attorno a questa distinzione. Utilizza artefatti sintetici, tra cui un file che uno scanner di firme non segnala ma il cui caricamento tenta un'operazione su database, e un altro con un ramo condizionale che rimane non eseguito. Il primo dimostra perché un tentativo osservato è importante. Il secondo evidenzia il problema di progettazione più complesso: decidere cosa fare quando i controlli disponibili sono in disaccordo senza fingere che il disaccordo sia stato risolto.

Le prove cambiano la decisione

Nell'esempio del database sintetico, PickleScan non segnala l'artefatto. Durante il caricamento, un hook di audit CPython configurato registra e blocca un tentativo di operazione sul database SQLite. La pipeline locale restituisce QUARANTINE e non emette alcuna firma. L'operazione sul database non è andata a buon fine; la prova utile è l'effetto tentato e il relativo blocco registrato.

Ciò fornisce alla decisione di ammissione una motivazione che il risultato pulito dello scanner non può offrire. Un team può indicare l'operazione vietata anziché chiedere all'etichetta dello scanner di rispondere a ogni domanda sul caricamento. Lo scanner rimane utile come confronto, ma l'assenza di una segnalazione non annulla un tentativo bloccato e osservato.

Preferisco questa separazione perché rende la decisione ispezionabile. Un revisore dovrebbe essere in grado di seguire la relazione tra un riscontro e un risultato. «L'hook configurato ha bloccato questo tentativo di operazione sul database» è un'affermazione circoscritta. Identifica la prova, il meccanismo e il motivo del verdetto locale. Un'etichetta di sicurezza generica lascerebbe nascoste tali relazioni.

Anche l'osservazione crea il proprio confine di attendibilità. Qui l'esecutore tenta il caricamento in un sottoprocesso Python e monitora gli eventi di audit configurati. Si tratta di una strumentazione di demo, con separazione dei processi, piuttosto che di un confinamento a livello di sistema operativo o container. Una progettazione per la produzione dovrebbe stabilire come l'esecutore dell'osservazione stesso viene isolato prima di affidargli artefatti non attendibili. L'aggiunta di prove comportamentali non elimina l'obbligo di esaminare l'ambiente che le raccoglie.

Un caricamento silenzioso lascia una domanda più difficile

Il fixture sintetico condizionale giunge a un esito diverso. L'ispezione statica individua builtins.eval, un elemento globale presente nell'elenco degli elementi pericolosi configurato nella demo. Il caricamento osservato non registra alcun evento pericoloso bloccato poiché il ramo condizionale non viene eseguito in questo ambiente. La pipeline indirizza l'artefatto a REVIEW, senza alcuna firma. Nessuna indagine umana è stata completata attraverso tale percorso.

Ci sono tre risposte difendibili da considerare, e ciascuna comporta costi diversi. L'approvazione accetta l'incertezza. Il rifiuto evita l'uso di questo artefatto, ma può scartare qualcosa che un'indagine più mirata potrebbe spiegare. Un'ulteriore revisione ritarda la decisione e richiede che qualcuno definisca quali prove aggiuntive potrebbero modificarla.

Per questo caso, preferisco la revisione perché l'incertezza è specifica. C'è un problema statico identificato e una lacuna identificata nell'osservazione. L'esecuzione silenziosa non spiega perché l'elemento globale pericoloso sia presente né cosa accada se il ramo viene raggiunto. L'approvazione richiederebbe di accettare tale lacuna. Un rifiuto immediato potrebbe essere una politica organizzativa ragionevole, ma sarebbe una scelta di escludere l'artefatto sulla base di prove statiche irrisolte, piuttosto che la dimostrazione che si è verificato un effetto vietato.

La distinzione è importante quando un team redige la propria politica di ammissione. La mancata osservazione di un effetto non dovrebbe diventare tacitamente la conclusione che l'effetto non può verificarsi. Allo stesso modo, il sospetto non dovrebbe diventare tacitamente la prova di un attacco riuscito. REVIEW offre uno spazio per mantenere entrambi i fatti mentre l'organizzazione sceglie quanta incertezza può accettare.

REVIEW richiede un criterio di uscita

Lo stato di revisione da solo può trasformarsi in una costosa area di stallo. Guadagna il suo posto solo quando il record spiega la questione irrisolta e la decisione successiva che qualcuno deve prendere. In questo esempio, la questione riguarda l'elemento globale statico e il ramo non esercitato. Ripetere lo stesso caricamento silenzioso senza modificare l'oggetto dell'indagine aggiungerebbe un'altra osservazione senza rispondere a tale domanda.

In un ipotetico processo aziendale, un team potrebbe ispezionare il ramo, cercare una spiegazione affidabile dal fornitore dell'artefatto o scegliere un artefatto sostitutivo con un percorso di caricamento più ispezionabile. Si tratta di risposte proposte, non di flussi di lavoro completati da questa demo. Ciascuna comporta un costo: un'ispezione più approfondita richiede competenze, le prove del fornitore richiedono una propria convalida e la sostituzione potrebbe sacrificare funzionalità necessarie. La scelta dipende da quali prove il team può ottenere e da quale incertezza la sua politica consente.

Voglio che tale scelta sia esplicita. Se nessuna indagine disponibile può risolvere il dubbio entro i vincoli del team, rifiutare l'artefatto può essere la conclusione appropriata della revisione. REVIEW non dovrebbe promettere che ogni file alla fine ottenga l'approvazione. Il suo scopo è evitare che una questione irrisolta scompaia in un verdetto e rendere la decisione finale responsabile nei confronti di una politica dichiarata.

La stessa disciplina si applica alle spiegazioni fornite dall'IA. Nella demo, un parere combinato di analista e challenger può introdurre cautela e spostare un risultato di base ALLOW su REVIEW; non può rimuovere QUARANTINE. La presentazione registrata utilizza pareri Codex memorizzati nella cache insieme a controlli configurati recenti. Un record di riferimento sintetico illustra il pericolo di trattare la narrativa come autorità: il suo parere raccomanda la firma e la promozione, mentre il risultato strutturato finale è REVIEW e non viene emessa alcuna firma.

Un utilizzatore dell'ammissione dovrebbe pertanto leggere il verdetto strutturato, la motivazione del gate e l'effettivo campo della firma. Una spiegazione utile può chiarire una decisione, ma il testo non deve diventare un secondo permesso contrastante per far avanzare un artefatto. Un processo di revisione che si fida della frase di raccomandazione anziché del gate finale ha perso la distinzione che doveva preservare.

Anche l'approvazione ha un confine

Il dizionario sintetico di pesi puliti riceve ALLOW e una firma sul nome del modello, sull'hash dell'artefatto e sul payload dell'inventario utilizzando una chiave di sviluppo locale. La provenienza dei suoi dati di addestramento e la cronologia di fine-tuning rimangono UNKNOWN. Solo ALLOW riceve tale firma; REVIEW e QUARANTINE non la ricevono.

Ciò è importante per l'uscita dalla revisione tanto quanto per il percorso pulito. Risolvere un dubbio sul caricamento non stabilirebbe, di per sé, la cronologia dell'addestramento. Una firma può autenticare il payload locale specificato rispetto alla sua chiave mentre una domanda a monte rimane senza risposta. Un team dovrebbe chiedersi separatamente se le prove di ammissione sono sufficienti per la decisione di caricamento e se la provenienza mancante è accettabile per l'uso previsto. Un controllo approvato non dovrebbe risolvere una questione che non ha mai esaminato.

La guida di Crucible illustra questi esempi locali e le relative prove. L'integrazione del registro, l'applicazione dell'ammissione aziendale e la custodia delle firme in produzione rimangono attività che vanno oltre questa demo. Il suo valore risiede nel confine decisionale che rende visibile, piuttosto che nella pretesa che l'implementazione locale fornisca tutti i controlli di cui un'azienda avrebbe bisogno.

Ecco il video del fondatore che illustra la demo locale di valutazione sintetica dei modelli.

Per un team di piattaforma che valuta un'architettura di ammissione, partirei dal caso in cui le prove non si allineano in modo lineare. Chiedetevi cosa mantiene visibile il riscontro irrisolto, chi decide se un'indagine più approfondita vale il suo costo e quali prove possono modificare il risultato. Un percorso lineare è facile da descrivere. Il percorso irrisolto rivela se il sistema preserva l'incertezza abbastanza a lungo da consentire una decisione responsabile.