La sicurezza dell'IA è soprattutto progettazione di sistemi

La sicurezza dell'IA è soprattutto progettazione di sistemi

La riunione sulla sicurezza dopo la demo

La demo era andata bene, come al solito. Il modello aveva letto una pila di documenti interni, risposto a una domanda sulle policy, suggerito un passo successivo e prodotto un riepilogo ordinato per il fascicolo del caso. Nella stanza annuirono. Qualcuno chiese se potesse essere collegato al sistema di workflow. Qualcun altro chiese quanto presto. Poi l'addetto alla sicurezza chiese cosa sarebbe successo se il modello avesse avuto torto ma fosse stato convincente. Nella stanza l'interesse per i biscotti divenne improvvisamente molto vivo.

È da quella domanda che parte la sicurezza pratica dell'IA. Non dall'astratto, e non da uno slogan. Dalla forma del sistema attorno a un modello che a volte sbaglia, a volte è obsoleto, a volte è troppo sicuro di sé, a volte troppo insicuro, e a volte ha ragione per il motivo sbagliato. Il problema di sicurezza non riguarda solo il comportamento del modello. Riguarda ciò che il sistema consente a quel comportamento di fare.

Un modello che abbozza una frase è un rischio. Un modello che aggiorna una decisione su una prestazione è un altro. Un modello che chiama uno strumento con accesso in scrittura è un altro ancora. Un modello che smista un paziente, respinge una richiesta, modifica un limite di credito o controlla delle apparecchiature si colloca in una classe di pericolo del tutto diversa. Lo stesso modello di base può essere innocuo, utile, rischioso o inaccettabile a seconda di confini, stato, prove, autorità, monitoraggio e ripristino. È per questo che la sicurezza dell'IA è in gran parte progettazione di sistemi.

In quella frase, "in gran parte" fa un lavoro importante. La ricerca sui modelli conta. La qualità dei dati conta. I metodi di allineamento contano. La scienza della valutazione conta. Ma quando un'organizzazione implementa l'IA, la sicurezza diventa operativa. Chi può chiedere. Cosa può vedere il modello. Cosa può modificare. Quale prova è richiesta. Quale stato viene preservato. Cosa succede quando le fonti sono in disaccordo. Quando deve intervenire un essere umano per approvare. Come viene rilevata la deriva. Come si annulla una release difettosa. Queste sono domande di progettazione prima di essere dichiarazioni etiche. La dichiarazione etica può essere sincera. Il sistema non esegue la sincerità.

La sicurezza è un problema di controllo

Quando le persone sentono la parola sicurezza, spesso pensano a valori, dati di addestramento, policy di rifiuto e allineamento del modello. Questi fanno parte del quadro, ma un sistema implementato ha bisogno anche di controlli. Un controllo è qualcosa che cambia ciò che può accadere: un controllo degli accessi, uno schema, un timeout, una soglia, un'approvazione umana, una sandbox, un limite di frequenza, un verificatore, un rollback, un interruttore di emergenza, un registro che non può essere modificato dal percorso di servizio. I controlli sono noiosi finché non mancano. Poi diventano l'argomento dell'intera riunione.

Un sistema di IA sicuro parte dal presupposto che il modello possa sbagliare e progetta di conseguenza la macchina che lo circonda. Separa la proposta dall'azione. Limita l'autorità degli strumenti. Verifica le prove prima di modificare lo stato. Rende visibile l'incertezza. Registra la versione del modello e l'ambito delle fonti. Rifiuta quando mancano i campi obbligatori. Offre agli operatori un modo per mettere in pausa l'automazione. Tratta l'output del modello come una candidatura, non come un verdetto emanato da un foglio di calcolo molto eloquente.

Questa è ordinaria ingegneria della sicurezza con un modello linguistico al centro. L'aviazione, la medicina, il settore ferroviario, il controllo industriale e la finanza hanno tutti imparato che i sistemi importanti richiedono controlli a più livelli perché nessun componente è perfetto. La versione con l'IA sembra nuova perché il componente parla. Il linguaggio rende il fallimento socialmente persuasivo. Una risposta sbagliata che suona calma può superare le difese di un operatore stanco più facilmente di un errore rosso lampeggiante. La progettazione dei controlli deve quindi essere più ostinata della prosa.

La progettazione dei controlli inizia chiedendosi su cosa al sistema è consentito agire. Se l'IA può solo redigere, la sicurezza si concentra sulla qualità delle fonti, sui controlli delle allucinazioni, sulla chiarezza dell'interfaccia utente e sulla revisione. Se può instradare il lavoro, la sicurezza aggiunge il tracciamento dello stato, l'integrità delle code, i livelli di servizio e i percorsi di ricorso. Se può chiamare strumenti, la sicurezza aggiunge ambiti di autorizzazione, validazione degli argomenti, registri delle transazioni e azioni compensative. Se può incidere su diritti o sistemi fisici, la sicurezza richiede prove, revisione formale, autonomia limitata e una seria pianificazione degli incidenti. Il modello è una parte. Il perimetro di autorità è l'altra.

Il confine è il prodotto

La linea più importante in un sistema di IA spesso non è visibile nell'interfaccia. È il confine tra leggere e scrivere, raccomandare e decidere, riassumere e registrare, assistere e agire. I confini deboli sono il modo in cui i prototipi innocui diventano servizi non sicuri. Un modello che inizia come ausilio alla redazione riceve un pulsante per applicare la bozza. Poi riceve uno strumento per aggiornare il caso. Poi riceve una regola di instradamento perché il team è occupato. Sei mesi dopo nessuno sa spiegare quali decisioni sono automatizzate e quali sono solo assistite. Non è malizia. È un'espansione dell'ambito che indossa scarpe comode.

I buoni confini sono espliciti e ispezionabili. Il modello può leggere queste fonti, non quelle. Può proporre questi campi, non impegnarli. Può chiamare questo strumento con questi argomenti, non con testo arbitrario. Può instradare i casi a basso rischio, non i casi contestati. Può rispondere solo quando le prove sono aggiornate. Non può usare note private per spiegazioni pubbliche. Non può passare da un tenant, una regione, un account o una base giuridica a un'altra solo perché il paragrafo successivo sembrava utile.

I confini devono anche essere applicati al di fuori del modello. Un prompt che dice di non scrivere nel database dei clienti non è un confine se lo strumento ha accesso in scrittura e nessun gateway. Un messaggio di sistema che dice di citare le fonti non è un confine se le risposte possono essere salvate senza citazioni. Un paragrafo di policy che dice che è richiesta l'approvazione umana non è un confine se il flusso di lavoro consente all'automazione di segnare come approvato. Le istruzioni di sicurezza dentro il modello sono utili, ma non bastano. Il sistema deve rendere i percorsi non sicuri difficili o impossibili.

Questo è il lavoro poco romantico che protegge davvero le persone. Chiamate di strumenti tipizzate. Ambiti ristretti. Impostazioni predefinite di sola lettura. Servizi di approvazione separati. Operazioni idempotenti. Registri di controllo. Policy con versioni. Stati delle code. Stati di rifiuto espliciti. Il vocabolario sembra quello di un ingegnere backend che ha passato un fine settimana tranquillo con una clipboard. Bene. La sicurezza in produzione di solito è così. Non cerca di vincere un concorso di slogan.

Lo stato è il punto in cui la sicurezza diventa reale

Le conversazioni con l'IA possono far sembrare i sistemi privi di stato. Un utente chiede, un modello risponde, lo schermo cambia. La produzione non è priva di stato. I casi avanzano. I ticket invecchiano. Le autorizzazioni scadono. I documenti vengono corretti. Una versione del modello cambia. Un essere umano ignora una raccomandazione. Arriva un ricorso. Un utente chiede perché qualcosa è accaduto il mese scorso. La sicurezza dipende dal fatto che il sistema abbia conservato lo stato necessario per rispondere.

Lo stato dice al sistema cosa è già accaduto e cosa può accadere dopo. Senza di esso, il modello vede una porzione e indovina il resto. È così che si verificano azioni duplicate, le scadenze svaniscono, le approvazioni vengono date per scontate e vecchie prove rientrano in una nuova decisione. Un flusso di lavoro sicuro registra stati espliciti: bozza, prove mancanti, bloccato dalla policy, revisione richiesta, approvato, eseguito, contestato, corretto, revocato. Questi stati non sono decorativi. Impediscono al modello di trattare un processo consequenziale come una trascrizione di chat con ambizioni.

Lo stato dà anche leva agli esseri umani. Un operatore può verificare perché un caso è in revisione. Un manager può vedere se l'automazione sta creando un arretrato. Un revisore può riprodurre quali versioni delle fonti erano attive. Un utente può contestare un esito con qualcosa di più solido di uno screenshot. Uno sviluppatore può misurare se un nuovo modello aumenta i rifiuti, le escalation o le rilavorazioni. Senza stato, ogni conversazione sulla sicurezza diventa teatro. Le persone parlano di responsabilità, ma il sistema ha smarrito i sostantivi.

Per l'IA, lo stato dovrebbe includere versione del modello e della policy, identificatore del prompt o del template, insieme delle fonti, timestamp del recupero, chiamate agli strumenti, confidenza o incertezza, motivo del rifiuto, azione umana ed effetto a valle. Non tutto questo appartiene a una singola riga di log, e non tutto dovrebbe essere visibile a tutti. Privacy e sicurezza contano. Ma l'informazione deve esistere con accesso controllato. Altrimenti la sicurezza dipende dalla memoria, e la memoria è un database notoriamente scadente con ottime scuse.

Le prove sono la barriera di sicurezza

La risposta di un modello è più sicura quando è collegata alle prove. Sembra ovvio finché il sistema non è sotto pressione. Le prove vengono saltate perché aggiungono latenza. Le citazioni sono memorizzate come testo anziché come identificatori. I punteggi di recupero non vengono conservati. Le versioni delle fonti vengono sovrascritte. Il modello scrive una spiegazione sicura di sé da un documento che nel frattempo è stato corretto. Poi tutti si chiedono perché la risposta era sbagliata. La risposta è che la barriera era decorativa.

Le prove utili non sono una nota a piè di pagina. Sono una catena. La richiesta è arrivata con un'identità e uno scopo. Le fonti sono state selezionate con autorizzazione. Il recupero ha trovato blocchi o record specifici. Il modello ha prodotto un output con una versione nominata. Un verificatore ha controllato affermazioni o soglie. Una persona ha accettato, modificato o rifiutato. L'azione ha cambiato lo stato. Il sistema ha conservato abbastanza di quella catena per riprodurla o contestarla. Non è burocrazia fine a se stessa. È così che la sicurezza sopravvive al tempo.

Le prove proteggono anche il modello dall'essere costretto a fare un lavoro impossibile. Se il sistema richiede fonti attuali, il modello può rifiutare input obsoleti. Se il sistema richiede due record corrispondenti, può segnalare un disaccordo. Se il sistema richiede identificatori di fonte, può fermare affermazioni non supportate. Il modello non deve più trasformare la mancanza di prove in una gestione fluente dell'incertezza. Può restituire uno stato sicuro. Questo è più gentile verso il modello e molto più gentile verso la persona che subisce l'output.

C'è un equilibrio. La raccolta di prove non deve diventare sorveglianza. I contenuti sensibili possono essere sottoposti a hash, oscurati, separati o conservati per periodi limitati. Il punto non è registrare tutto per sempre. Il punto è preservare i fatti necessari per ispezionare comportamenti importanti. La sicurezza senza prove è solo fiducia con una giacca più bella. Può sembrare a posto all'ingresso. Non regge in un incidente.

Gli esseri umani hanno bisogno di autorità progettata

L'umano nel circuito è spesso usato come una frase magica. Non è magia. Un revisore stanco con prove deboli, policy poco chiare e una coda di duecento casi non è un sistema di sicurezza. È una persona messa alla fine di un nastro trasportatore a cui si chiede di fare da governance. Può funzionare brevemente, soprattutto se la persona è esperta e testarda. Non è un progetto.

L'autorità umana deve essere specifica. Quali casi richiedono revisione. Quali prove vede il revisore. Il revisore può modificare campi strutturati o solo approvare testo. Il revisore sa se il modello era incerto o se la policy richiedeva un'escalation. I disaccordi vengono reimmessi nella valutazione. I revisori sono protetti dal bias di automazione. Possono mettere in pausa un flusso di lavoro. Possono escalare a uno specialista. Possono vedere casi simili passati. Possono spiegare una decisione alla persona coinvolta. Questi dettagli decidono se la supervisione umana è reale o ornamentale.

Una buona supervisione separa anche il giudizio dal recupero meccanico. Le persone non dovrebbero passare il tempo a cercare identificatori di origine mancanti, a deduplicare i nuovi tentativi, a tradurre la prosa del modello in stati del flusso di lavoro o a indovinare quale versione della policy si applicava. Il sistema dovrebbe preparare il caso. L'essere umano dovrebbe applicare il giudizio dove serve: significato contestato, eccezioni, proporzionalità, contesto, empatia e responsabilità. Se l'essere umano passa la maggior parte del tempo a colmare lacune infrastrutturali, l'organizzazione ha confuso l'organico con la sicurezza.

Il design deve anche consentire agli esseri umani di dissentire dall'automazione senza che l'attrito diventi una punizione. Se ignorare il modello richiede otto clic e accettarlo ne richiede uno, l'interfaccia ha una policy. Se l'escalation fa sembrare un team lento, le persone eviteranno l'escalation. Se le metriche premiano solo la produttività, le revisioni di sicurezza diventeranno cerimoniali. La progettazione dei sistemi include incentivi, schermate, code e impostazioni predefinite. Il modello potrebbe non conoscere la metrica, ma le persone di certo la conosceranno.

La località modifica il rischio

Il luogo in cui avviene il lavoro di IA è importante. Un sistema che invia ogni documento a un modello remoto ha rischi diversi da uno che esegue l'estrazione vicino ai dati e invia solo un campo derivato. Un sistema che archivia le tracce nel servizio di erogazione ha rischi diversi da uno che conserva registri di audit indipendenti. Un sistema che dipende da un singolo router esterno ha opzioni di ripristino diverse da uno che può degradarsi localmente. La località non è nazionalismo con un diagramma di rete. È la questione pratica di quali rischi si spostano quando si spostano dati, calcolo, policy e prove.

Parte del lavoro dovrebbe avvenire vicino ai dati sensibili perché spostare i dati crea esposizione. Parte del lavoro dovrebbe avvenire vicino agli utenti perché la latenza influisce sulla sicurezza. Parte del lavoro dovrebbe avvenire in un servizio centrale perché sono necessarie revisioni specializzate o hardware. Alcune prove dovrebbero essere archiviate lontano dal percorso di erogazione del modello perché quel percorso potrebbe essere proprio l'oggetto dell'indagine. Il design sicuro raramente è tutto locale o tutto remoto. È un posizionamento deliberato.

La località influisce anche sulla responsabilità legale e organizzativa. Se una chiamata al modello attraversa le regioni, quale legge disciplina i dati. Se un indice viene creato al di fuori del sistema di origine, come vengono propagate le eliminazioni. Se un fornitore modifica un modello, come viene ricevuta la notifica ed eseguito il test. Se i log risiedono nel portale del fornitore, l'organizzazione può esportarli durante un incidente. Queste non sono questioni astratte di sovranità. Sono questioni di sicurezza perché determinano se l'organizzazione può controllare e spiegare il sistema sotto stress.

Un posizionamento errato può rendere costoso il comportamento sicuro. Se ogni fase di verifica richiede un round trip remoto, i team potrebbero campionare invece di controllare ogni caso. Se i dati di audit sono difficili da correlare, le indagini diventano lente. Se i dati privati devono viaggiare per una semplice classificazione, il rischio aumenta senza alcun beneficio. Una buona progettazione della località riduce il costo di fare la cosa sicura. Questo è importante perché i controlli troppo costosi verranno prima o poi descritti come opzionali, ed è così che iniziano molte storie negative.

La valutazione deve seguire il sistema

Molti team valutano il modello e dimenticano di valutare il sistema. Testano se le risposte sono corrette su un insieme di prompt, poi distribuiscono in un flusso di lavoro con permessi, freschezza delle fonti, code, chiamate agli strumenti, revisione umana, tentativi e politiche mutevoli. Il benchmark del modello può essere ancora utile, ma non descrive più l'intero rischio. I fallimenti di sicurezza vivono spesso nelle giunzioni.

Una valutazione di sistema testa il comportamento end-to-end. Chiede se la fonte giusta viene recuperata per l'utente giusto. Controlla se i dati obsoleti vengono rifiutati. Verifica che le chiamate agli strumenti siano bloccate senza permesso. Misura se i casi ad alto rischio raggiungono gli esseri umani. Testa il rollback. Testa il ritardo della coda. Testa i percorsi di aggiornamento del modello. Testa casi strani ma ordinari: data mancante, cliente duplicato, eccezione regionale, ricorso dopo la correzione, cancellazione della fonte, interruzione parziale, revisore sovraccarico. La produzione ha un gusto per i casi che nessuno pensava fossero abbastanza drammatici.

La valutazione dovrebbe includere la capacità negativa. Il sistema deve essere bravo a non fare cose. Non rispondere senza prove. Non oltrepassare i confini dei permessi. Non passare all'azione quando è consentita solo la bozza. Non nascondere l'incertezza. Non usare una fonte dopo la cancellazione. Non continuare quando uno strumento restituisce uno stato incoerente. La sicurezza dipende tanto dal rifiuto e dalla pausa quanto dall'accuratezza. L'output più importante di un sistema di IA sicuro può essere prove insufficienti, una frase che nessun team demo mette mai su uno striscione.

La valutazione del sistema cambia anche la gestione del rilascio. Un cambiamento di prompt, un cambiamento di modello, una ricostruzione dell'indice, un aggiornamento delle politiche, un cambiamento dei permessi degli strumenti o un cambiamento dell'interfaccia del revisore possono alterare la sicurezza. Ognuno richiede un ambito di test e un piano di rollback. Il team dovrebbe sapere quali comportamenti sono cambiati e quali rischi sono aumentati. Questo è noioso nel modo in cui le cinture di sicurezza sono noiose. Diventa interessante solo quando è assente, il che è troppo tardi per essere comodi.

La lezione

La sicurezza dell'IA è per lo più progettazione di sistemi perché il danno viaggia di solito attraverso i sistemi. Un output del modello diventa rischioso quando un flusso di lavoro si fida troppo di esso, un gateway degli strumenti è troppo ampio, le prove mancano, lo stato è vago, la revisione è sovraccarica, i log sono deboli o il rollback è immaginario. Il modello può essere la fonte visibile della frase, ma il sistema decide se la frase diventa azione.

Questa prospettiva è meno drammatica di molti dibattiti sulla sicurezza dell'IA, ed è più utile per le organizzazioni che implementano sistemi oggi. Chiede ai team di tracciare confini, nominare l'autorità, preservare le prove, progettare gli stati, collocare il lavoro in modo deliberato, valutare end to end e dare agli esseri umani un potere reale. Tratta il modello come un componente potente in un safety case, non come l'intero safety case. Questa è la posizione adulta. Dà inoltre agli ingegneri qualcosa da costruire oltre a un altro PDF di policy, il che è gentile verso tutti.

La domanda del responsabile della sicurezza dopo la demo era esattamente giusta. Cosa succede se il modello sbaglia ma è persuasivo. Un sistema sicuro dovrebbe avere una risposta: qui può solo abbozzare, lì deve citare fonti attuali, non può chiamare quello strumento, questo caso va in revisione, questa azione lascia una ricevuta, questo flusso di lavoro può essere messo in pausa, questa release può essere annullata, questa decisione può essere contestata. Quelle risposte non sono vibrazioni. Sono design.

Ci sarà sempre incertezza nell'IA. Il compito pratico è impedire che l'incertezza diventi autorità senza limiti. Questo si ottiene con interfacce, stati, controlli, prove, località, valutazione, recupero e giudizio umano adeguatamente attrezzato. In altre parole, progettazione di sistemi. Non perché i valori non contino, ma perché i valori devono essere resi eseguibili prima di poter proteggere chiunque.