Una raccomandazione di prestito dell'IA richiede una regola di rilascio autonoma

Una raccomandazione di prestito può apparire ragionevole e al contempo contraddire la policy che dovrebbe seguire. Desidero che la decisione di rilasciare tale raccomandazione poggi su una base autonoma e ispezionabile. Se la spiegazione e l'autorizzazione ad agire scaturiscono dalla medesima risposta, un revisore deve districare entrambe prima di decidere che cosa possa procedere.

Il quesito di progettazione riguarda cosa debba accadere quando una raccomandazione dell'IA fallisce un controllo. Chiedere al modello di riprovare può correggere una risposta incompleta. Sospendere la raccomandazione può essere indispensabile quando essa contraddice una regola. Si tratta di interventi distinti, con costi differenti. Un confine utile rende visibile tale differenza prima che l'una o l'altra diventi un'abitudine automatica.

Una spiegazione ragionevole può supportare un esito errato

In The Validation Firewall di Veriprajna, l'output conservato di un modello raccomanda l'approvazione per un richiedente prestito sintetico con un punteggio di credito pari a 559. La policy configurata richiede almeno 620. La raccomandazione viola inoltre i criteri di policy relativi al rapporto debito/reddito (debt-to-income), rapporto prestito/valore (loan-to-value) e morosità recenti.

Si tratta di risposte del modello memorizzate nella cache su record sintetici, rieseguite attraverso i controlli senza nuova inferenza. Illustrano il comportamento di questo esempio, non un benchmark di accuratezza del modello né evidenze tratte dai clienti di un istituto di credito. Il flusso di erogazione e l'instradamento sono simulati.

La spiegazione è istruttiva. Indica che la policy fornita non mette a disposizione le chiavi dei motivi principali consentiti necessarie per una negazione. Ciò mette a nudo un reale limite del contratto di input: il prompt del modello nella demo fornisce i criteri di credito, ma omette l'elenco dei motivi consentiti che prescrive al modello di utilizzare. La risposta del modello merita di essere compresa in questo contesto. Non rappresenta una base equa per classificare i modelli.

Inoltre, non rende l'approvazione coerente con i criteri di credito codificati. L'assenza di istruzioni per motivare un rifiuto non modifica il punteggio di credito del richiedente né la soglia minima della policy. Una risposta può individuare correttamente un problema e raccomandare comunque un esito che vìola un altro requisito.

In questo caso preferisco una valutazione separata della policy perché preserva tale distinzione. Il modello può chiarire perché il suo compito fosse difficoltoso. Il controllo può evidenziare perché questa raccomandazione non soddisfi la regola fornita. Un revisore può ispezionare entrambi senza trattare una spiegazione persuasiva come l'autorità per modificare la regola.

Tale separazione rende anche la correzione più mirata. Perfezionare l'elenco dei motivi nel prompt sistema il contratto di risposta. Modificare una soglia minima di policy è una decisione differente che necessita di una propria giustificazione. Continuare a richiedere una spiegazione più convincente non può stabilire quale policy debba essere applicata.

Nuovo tentativo e revisione umana risolvono problemi differenti

Si consideri un ipotetico flusso operativo di produzione che adotta questo modello. Giunge una risposta di rifiuto priva della motivazione strutturata richiesta. Un'opzione consiste nel sollecitare una risposta corretta fornendo le istruzioni mancanti. Un'altra consiste nell'inviarla direttamente a un revisore. La prima può essere adatta per un problema di formattazione o di input recuperabile; la seconda riserva l'attenzione per i casi in cui la decisione sottesa richieda giudizio umano.

Favorisco un nuovo tentativo circoscritto quando il difetto è specifico, l'input può essere corretto e la risposta sostitutiva sarà sottoposta ai medesimi controlli. La risposta precedente deve rimanere consultabile accanto alla sua sostituta. Altrimenti, una successiva risposta impeccabile può nascondere il fatto che il contratto originale sia fallito. Questa è una raccomandazione architetturale, non una capacità di retry o di tracciamento versioni dimostrata da questo prototipo.

L'approvazione che vìola la policy richiede un trattamento ben diverso. Un nuovo tentativo potrebbe generare una raccomandazione conforme, ma l'approvazione originaria deve restare bloccata. La condizione di rilascio deve fare riferimento a un risultato appena controllato. Non deve ridursi a: «il modello ha risposto due volte» o «la spiegazione adesso sembra migliore». Se il caso esige una deroga alla policy, un processo autorizzato di gestione eccezioni deve fornire tale autorità.

Questa scelta comporta un costo. Trattenere tutto per la revisione umana satura la capacità dei revisori e ritarda pratiche che un input corretto potrebbe risolvere immediatamente. Riprovare a fronte di ogni fallimento consuma risorse di calcolo e può innescare una serie di alternative plausibili senza dirimere la regola applicabile. La linea di demarcazione utile consiste nel valutare se il difetto possa essere corretto nell'ambito del contratto decisionale esistente o se richieda che qualcuno modifichi tale contratto.

Gli esiti effettivi del prototipo sono più circoscritti. Un controllo fallito con gravità di blocco produce BLOCK. Un fallimento con gravità di escalation produce ESCALATE qualora nessun blocco abbia la priorità. Superare tutti e quattro i singoli controlli genera AUTO-CLEAR. Queste etichette registrano il verdetto del gate configurato. Non dimostrano una revisione umana completata né l'autorizzazione a rilasciare una decisione di credito in produzione.

Un controllo superato necessita di una dichiarazione di copertura

La complicazione successiva riguarda ciò che un esito positivo può ragionevolmente significare. Un controllo esterno può essere deterministico e lasciare comunque senza risposta interrogativi fondamentali. La precisione della regola non dimostra la completezza della sua copertura.

Ad esempio, questa demo confronta le evidenze valore-campo fornite con una raccomandazione rispetto al record sintetico. Ciò è prezioso quando un valore citato è scorretto. Tuttavia, un elenco di evidenze vuoto supera tale controllo. Esso non esamina ogni asserzione contenuta nella spiegazione né accerta che ogni campo necessario sia stato citato.

Desidero pertanto che una regola di rilascio dichiari sia il predicato che valuta, sia l'evidenza che richiede. In un flusso ipotetico in cui una decisione debba poggiare su un reddito verificato, l'assenza della citazione del reddito richiede un trattamento esplicito. Il progettista potrebbe imporre il campo prima della convalida, instradare l'evidenza mancante verso una revisione, oppure restringere l'incarico affinché la raccomandazione non abbia alcuna autorità su tale decisione. Un controllo di coerenza da solo non può scegliere tra queste policy.

Richiedere maggiori evidenze comporta un compromesso. Può rendere visibili le omissioni, ma accresce anche il contratto di risposta e l'onere necessario per mantenerlo. L'evidenza richiesta deve essere commisurata alle conseguenze della decisione. Pretendere ogni campo disponibile crea rumore di fondo; richiedere soltanto ciò che il modello decide spontaneamente di offrire lascia al modello il controllo sulla copertura del controllo.

AUTO-CLEAR deve essere interpretato con questo perimetro esplicito. Significa che i controlli individuali implementati sono stati superati, e può applicarsi tanto a un rifiuto supportato dalla policy quanto a un'approvazione. Non sancisce che il prestito debba essere concesso, che ogni fatto sia esatto o che tutti i pertinenti obblighi normativi siano stati assolti.

Un'approvazione aggregata non può sanare un fallimento individuale

Il medesimo batch conservato del modello offre un banco di prova illuminante per l'interpretazione dei dashboard. Ciascuno dei suoi due gruppi sintetici conta cinque approvazioni previste su sei record. Il relativo rapporto tra tassi di approvazione previsti è pari a 1.00, per cui lo screening del portafoglio configurato risulta superato. Ciononostante, l'approvazione contraria alla policy rimane bloccata a livello individuale.

Non vi è alcuna contraddizione. Il pannello del portafoglio confronta i tassi di gruppo tra le raccomandazioni previste. Il controllo individuale confronta una singola raccomandazione con la policy configurata. L'uno non sostituisce l'altro. Con soli sei record sintetici per gruppo, l'approvazione aggregata non può nemmeno certificare la conformità normativa o un comportamento affidabile al di fuori di questo esempio.

Mantengo tali questioni rigorosamente separate quando interpreto un dashboard di convalida. Un unico riepilogo verde induce i lettori ad attribuirgli un significato più esteso di quanto il calcolo sottostante autorizzi. Un migliore registro di revisione individua quale domanda trovi risposta in ciascun risultato, i record inclusi e le condizioni irrisolte. Il report esplicativo della demo mostra come questi riscontri individuali e lo screening del portafoglio si affianchino l'uno all'altro.

Ecco la mia disamina degli esempi sintetici e dei riscontri dei rispettivi controlli.

Per un team che debba stabilire dove collocare un confine di rilascio, il mio criterio è se un revisore possa ricondurre l'autorizzazione a una regola specifica, alle evidenze richieste e a un passaggio successivo tracciabile. La spiegazione di un modello può arricchire tale documentazione. Non deve tuttavia acquisire l'autorità di attenuare una regola violata semplicemente illustrando perché seguirla fosse complicato.