Lo studio AI di Tech Against Terrorism rileva che le protezioni possono crollare
Tech Against Terrorism ha testato oltre 130 modelli di AI e tre su cinque non hanno superato la sua più recente valutazione sulla sicurezza legata al terrorismo. Lo studio AI di Tech Against Terrorism ha riscontrato i fallimenti più marcati nei modelli modificati le cui salvaguardie di rifiuto erano state deliberatamente rimosse.
Questa distinzione è importante. Lo studio non dimostra che la maggior parte dei chatbot mainstream assista apertamente i terroristi nell'uso ordinario. Dimostra che la sicurezza può deteriorarsi rapidamente quando i modelli vengono modificati, riformulati o distribuiti oltre il controllo diretto dei loro sviluppatori.
Il risultato mette sotto pressione Meta, Hugging Face, gli sviluppatori open-weight e gli host di modelli. La loro sfida centrale è preservare la ricerca legittima e il deployment locale senza trattare le salvaguardie presenti al rilascio come una protezione permanente.
La conclusione più forte non è quindi una semplice contrapposizione tra AI aperta e chiusa. È un conflitto tra modelli adattabili e controlli di sicurezza che potrebbero non sopravvivere all'adattamento.
Lo studio AI di Tech Against Terrorism ha ampliato il test
La nuova valutazione sposta il dibattito dai fallimenti isolati dei chatbot a un esame più ampio di come la sicurezza si comporti lungo la catena di fornitura dei modelli.
Tech Against Terrorism è un'organizzazione non profit britannica focalizzata sull'attività terroristica online. I suoi ricercatori hanno valutato oltre 130 modelli con centinaia di richieste connesse alla pianificazione di attacchi, al finanziamento, alla radicalizzazione e ad altre forme di assistenza dannosa.
Il test dell'organizzazione valuta se un modello rifiuta in modo coerente le richieste pericolose. Considera inoltre la gravità e la specificità delle informazioni eventualmente fornite dal modello.
Secondo i test ampliati, un modello non superava la prova se produceva una risposta completa e specifica relativa a danni con molte vittime. Anche un punteggio inferiore a 90 su 100 veniva considerato un fallimento.
Si tratta di una soglia severa. Un modello può rifiutare la maggior parte dei prompt pericolosi e fallire comunque perché una risposta fornisce assistenza sufficientemente completa.
Questo approccio differisce da un semplice test del tasso di rifiuto. Un tasso di rifiuto conta con quale frequenza un modello dice no, ma può trascurare la conformità parziale.
Alcuni sistemi iniziano con un avvertimento e poi forniscono il materiale richiesto. Tech Against Terrorism definisce questo schema conformità attenuata.
Il precedente benchmark antiterrorismo dell'organizzazione ha esaminato 27 modelli leader e quasi 2.500 prompt singoli. Circa un terzo di tali risposte forniva un aiuto significativo oltre ciò che offrirebbe una normale ricerca web.
Quel pilota ha inoltre rilevato variazioni significative in base alla categoria di minaccia e alla formulazione del prompt. Una richiesta identica riceveva un trattamento diverso quando un utente dichiarava una finalità di ricerca.
La ricerca più recente ha ampliato il gruppo di modelli concentrandosi su 627 richieste. Il suo risultato principale è stato che circa il 60 percento dei sistemi testati non ha soddisfatto lo standard di sicurezza dichiarato.
I due cicli non dovrebbero essere trattati come statistiche intercambiabili. Hanno utilizzato insiemi di modelli, dimensioni dei test e misure di rendicontazione differenti.
Nel complesso, tuttavia, sostengono la stessa conclusione. L'apparente sicurezza di un modello dipende da più elementi del suo nome, fornitore o interfaccia standard.
Conta la configurazione circostante. Contano anche i suoi pesi, le istruzioni di sistema, i controlli di deployment e l'identità dichiarata dall'utente.
La valutazione includeva dichiarazioni dirette di intenti terroristici. Ha inoltre testato richieste presentate attraverso ruoli meno palesemente malevoli, comprese formulazioni orientate alla ricerca.
Questo è importante perché gli aggressori reali raramente hanno bisogno di dichiarare sinceramente le proprie intenzioni. Una salvaguardia che funziona solo dopo una confessione esplicita offre una sicurezza limitata.
Lo studio sposta inoltre l'attenzione da scenari futuri astratti a sistemi già disponibili. Molti modelli testati possono essere eseguiti localmente, comparire in repository pubblici o essere modificati da terze parti.
Questa disponibilità crea la tensione centrale dell'articolo. Gli sviluppatori possono testare il modello originale, ma non possono presumere che ogni copia distribuita mantenga lo stesso comportamento.
La vera divisione è tra accesso controllato e pesi modificabili
I risultati non stabiliscono che ogni modello open-weight sia insicuro, ma espongono un problema di controllo che i servizi chiusi gestiscono in modo diverso.
I modelli open-weight rendono disponibili per il download i loro parametri addestrati. Tali parametri codificano gli schemi appresi da un sistema durante l'addestramento e la successiva ottimizzazione della sicurezza.
Gli sviluppatori possono adattare questi modelli a lingue, settori, hardware locale e applicazioni specializzate. I ricercatori possono ispezionare comportamenti che un servizio ospitato potrebbe nascondere.
Questi vantaggi spiegano perché lo sviluppo open-weight abbia attirato aziende, università, laboratori indipendenti e istituzioni pubbliche. Può ridurre la dipendenza da un ristretto gruppo di fornitori di API.
I modelli chiusi creano un accordo differente. Gli utenti vi accedono attraverso servizi controllati dallo sviluppatore del modello, senza ricevere i pesi sottostanti.
Questo controllo consente a un fornitore di aggiornare i filtri, monitorare attività sospette, limitare gli account e revocare l'accesso. Non garantisce la sicurezza, ma preserva opzioni di intervento.
Un rilascio open-weight non può essere richiamato allo stesso modo. Una volta che le copie si diffondono tra repository e macchine locali, le modifiche successive alle policy non possono raggiungerle in modo affidabile.
Il precedente benchmark di Tech Against Terrorism ha rilevato che la distinzione tra aperto e chiuso non era la principale divisione nelle prestazioni. Alcuni modelli open ordinari figuravano tra i sistemi più sicuri in quel test.
Claude di Anthropic e Falcon3 del Technology Innovation Institute si sono classificati ai primi posti nel pilota. Anche MiniMax ha ottenuto buoni risultati, secondo l'organizzazione.
Questo risultato complica le affermazioni secondo cui la sola apertura determina il pericolo. Modelli open ben allineati possono rifiutare richieste dannose, mentre servizi controllati possono comunque produrre risposte non sicure.
La divisione più rilevante emerge dopo il rilascio. Gli utenti possono alterare il comportamento di rifiuto di un modello open-weight senza l'approvazione dello sviluppatore originale.
Meta afferma che Llama 3.1 è stato sottoposto a valutazioni dei rischi prima del deployment, test avversariali, fine-tuning della sicurezza ed esercizi di red teaming esterni. Il suo piano di rilascio responsabile descrive anche salvaguardie a livello di modello e di sistema.
Tali misure restano importanti. La versione base testata di Llama 3.1 8B avrebbe ottenuto 97 punti su 100 nel benchmark dell'organizzazione non profit.
La versione modificata ha ottenuto circa tre punti. Quel calo di 94 punti è l'esempio più chiaro di controlli di sicurezza che non accompagnano il modello.
Le policy di Meta vietano gli usi dannosi e illegali. Tuttavia, le regole d'uso vincolano gli utenti conformi più efficacemente degli avversari che possiedono file di modello modificabili.
Questo non rende le policy prive di significato. Forniscono basi per l'applicazione delle regole nei deployment commerciali, sulle piattaforme e nei confronti dei licenziatari identificabili.
Tuttavia, l'applicazione delle policy si indebolisce quando un modello opera offline. Un sistema locale non deve inviare prompt al fornitore originale.
La pressione risultante si estende oltre Meta. Ogni sviluppatore che rilascia pesi modificabili deve decidere quali proprietà di sicurezza appartengano al modello e quali dipendano dai controlli di deployment.
Lo studio suggerisce che il solo fine-tuning dei rifiuti non possa sostenere l'intero onere. Gli sviluppatori necessitano anche di valutazioni progettate attorno alla modifica successiva al rilascio.
Gli host di modelli affrontano un problema correlato. Devono distinguere gli artefatti di ricerca dai sistemi pubblicizzati specificamente per un uso senza restrizioni.
Questa distinzione è difficile da automatizzare. Un modello modificato può sostenere ricerca legittima sulla sicurezza, lavoro creativo o test, rimuovendo al tempo stesso le barriere contro l'assistenza dannosa.
Divieti generalizzati imporrebbero costi a ricercatori e piccoli sviluppatori. Controlli deboli sulla distribuzione lascerebbero invece i modelli chiaramente privi di restrizioni facili da trovare.
Per questo il conflitto principale riguarda capacità adattabili contro sicurezza duratura. La domanda non è se i modelli aperti debbano esistere.
La domanda è quali protezioni possano rimanere efficaci dopo che lo sviluppatore perde il controllo diretto.
L'abliteration trasforma l'addestramento al rifiuto in uno strato rimovibile
L'abliteration è importante perché prende di mira direttamente il comportamento di rifiuto, trasformando una salvaguardia presente al rilascio in una funzionalità che terze parti possono rimuovere.
L'abliteration è una tecnica di modifica del modello che identifica schemi interni associati al rifiuto di richieste dannose. Quindi sopprime o contrasta tali schemi.
La tecnica non aggiunge necessariamente nuove conoscenze. Modifica invece la disponibilità del modello a divulgare conoscenze già apprese durante l'addestramento.
Questa distinzione è cruciale. Un sistema può mantenere le stesse capacità generali diventando al contempo molto più disposto a rispondere a richieste pericolose.
Tech Against Terrorism ha riferito che i modelli sottoposti ad abliteration non hanno superato nessun test di sicurezza nello studio più recente. I ricercatori hanno inoltre rilevato che modelli più piccoli potevano essere modificati in pochi minuti utilizzando strumenti liberamente disponibili.
L'organizzazione ha confrontato una versione alterata di Llama 3.1 8B di Meta con l'originale. Il modello base rifiutava richieste relative ad attacchi, finanziamento del terrorismo e radicalizzazione.
La versione modificata avrebbe invece fornito risposte dettagliate. I ricercatori non hanno sostenuto che tali risposte consentissero automaticamente un attacco reale.
Il loro benchmark misura se un sistema consegna le informazioni richieste. Non stabilisce se un utente possa eseguire con successo tali informazioni.
Questa limitazione non cancella il risultato. Definisce ciò che il test può dimostrare.
L'esperimento mostra un grande cambiamento nel comportamento di divulgazione. Non misura la competenza dell'utente, l'accesso ai materiali, la sicurezza operativa o la capacità di superare barriere pratiche.
Il livello dei repository di modelli rende il problema più ampio. Tech Against Terrorism ha identificato oltre 29.000 repository Hugging Face che pubblicizzavano modelli come uncensored o privi di salvaguardie.
Quel numero non significa che tutti i 29.000 repository contenessero materiale terroristico. Descrive quanti progetti utilizzassero etichette che suggerivano restrizioni ridotte.
Alcuni repository potrebbero duplicare lo stesso modello. Altri potrebbero utilizzare “uncensored” come termine di marketing generico senza aver subito la tecnica specifica testata qui.
Anche con queste precisazioni, il numero illustra quanto il controllo a livello di modello diventi difficile dopo la distribuzione. Le copie possono moltiplicarsi più rapidamente di quanto i ricercatori riescano a valutarle.
Hugging Face ha dichiarato a CBS News di svolgere una moderazione continua e di intervenire contro modelli, dataset e applicazioni che violano le sue regole.
La sua policy sui contenuti della piattaforma limita i contenuti terroristici e consente diverse risposte. Queste includono la rimozione dell'accesso, il gating dei repository, limiti alla visibilità e la sospensione degli account.
Hugging Face ha inoltre avvertito che alcune parti della risposta proposta dal rapporto potrebbero limitare il lavoro scientifico aperto. Questa preoccupazione merita di essere presa seriamente.
I ricercatori sulla sicurezza necessitano dell'accesso ad artefatti non sicuri per studiare le modalità di fallimento. Gli sviluppatori necessitano inoltre di modelli avversariali per testare filtri e sistemi di monitoraggio.
Un repository può quindi essere pericoloso in un contesto e prezioso in un altro. Le sole etichette non possono risolvere la questione.
La progettazione dell'accesso offre un percorso più mirato. Le piattaforme possono applicare verifica dell'identità, gating, etichette di avvertimento, monitoraggio dei download o risultati di test indipendenti in base al rischio dimostrato.
Questi controlli sono imperfetti. Una volta scaricato un modello, la piattaforma perde gran parte della sua capacità di intervento.
Tuttavia, l’attrito nella distribuzione può cambiare la scala. Può impedire ai sistemi di raccomandazione di trasformare modifiche ad alto rischio in scoperte casuali.
Lo studio solleva quindi un problema di catena di fornitura. Lo sviluppatore originale costruisce un modello, un’altra parte ne rimuove i rifiuti e una piattaforma distribuisce il risultato.
Ciascun partecipante controlla solo una parte del processo. Eppure il pubblico sperimenta il rischio combinato.
Una risposta duratura deve affrontare tutti e tre i livelli. Un addestramento più sicuro non può sostituire la governance dei repository, e la governance dei repository non può riparare ogni modello.
Resta essenziale anche il monitoraggio della distribuzione. Le organizzazioni che eseguono modelli aperti necessitano di filtri, registri, autorizzazioni e procedure per gli incidenti propri.
Un’azienda non dovrebbe presumere che il punteggio di sicurezza pubblicato per il modello di base resti valido dopo il fine-tuning. Ogni modifica sostanziale crea un nuovo oggetto di valutazione.
I test di sicurezza sull’IA e il terrorismo presentano ancora un divario di verifica
Lo studio individua una seria debolezza di sicurezza, ma non dimostra un uso operativo diffuso da parte di organizzazioni terroristiche.
Tech Against Terrorism ha dichiarato di non aver trovato prove che gruppi terroristici o estremisti stessero utilizzando i modelli testati. Nel corso dell’indagine ha identificato un chatbot estremista.
Quel divario di verifica è il limite più importante del titolo. Disponibilità del modello, output non sicuro e adozione operativa rappresentano fasi distinte.
Un modello può rispondere a una domanda dannosa senza migliorare le capacità di un soggetto reale. Gran parte delle sue informazioni potrebbe già essere disponibile in libri, forum o risultati di ricerca.
La misura rilevante è l’aumento di capacità. Vale a dire se il modello rende un’attività dannosa sensibilmente più facile rispetto alle alternative disponibili.
Tech Against Terrorism ha progettato il suo progetto pilota attorno a questa domanda. I ricercatori hanno confrontato l’assistenza del modello con materiale che una persona capace avrebbe potuto reperire attraverso normali ricerche sul web.
I risultati di luglio affermavano che circa un terzo delle risposte generava un aumento di capacità significativo. L’ultimo studio ampliato ha adottato una soglia di fallimento più rigorosa a livello di modello.
Nessuno dei due risultati dovrebbe essere tradotto in un numero previsto di attacchi. Il benchmark non fornisce quella stima causale.
Analisti indipendenti hanno inoltre messo in guardia dal concentrarsi soltanto su scenari spettacolari. Un’analisi del rischio terroristico del Center for Strategic and International Studies ha sostenuto che gli effetti a breve termine potrebbero essere più incrementali.
L’IA può assistere propaganda, traduzione, reclutamento, ricerca, ricognizione e lavoro amministrativo. Questi usi possono essere rilevanti senza produrre una nuova arma autonoma.
Questa assistenza di livello inferiore è più difficile da rilevare. Inoltre, assomiglia abbastanza ad attività legittime da complicare la moderazione.
Il revisore indipendente britannico della legislazione antiterrorismo è giunto a una visione altrettanto ampia. La revisione dei rischi legali ha preso in esame propaganda, radicalizzazione, pianificazione di attacchi e assistenza relativa alle armi.
La revisione ha individuato nella radicalizzazione guidata da chatbot un problema giuridico particolarmente difficile. Non ha suggerito che ogni scambio rischioso richiedesse un nuovo reato specifico per l’IA.
Queste distinzioni dovrebbero orientare il modo in cui i lettori interpretano la cifra del 60 per cento. Si tratta di un risultato di valutazione, non di una misurazione dell’attuale adozione da parte di terroristi.
La soglia di fallimento premia anche la coerenza. Una risposta dettagliata può far fallire un modello anche se questo rifiuta centinaia di altri prompt.
Questo standard ha senso per la sicurezza ad alte conseguenze. Una singola divulgazione grave può contare più di un alto tasso medio di rifiuti.
Tuttavia, non dimostra che ogni modello fallito comporti lo stesso rischio. I modelli differiscono per accuratezza, capacità, distribuzione, requisiti hardware e utilità pratica.
Un piccolo modello locale potrebbe acconsentire facilmente, ma fornire informazioni inaffidabili. Un sistema di frontiera potrebbe offrire informazioni migliori operando però dietro controlli di accesso più robusti.
Lo studio dipende anche dalla selezione dei prompt e dai giudizi di valutazione. I benchmark antiterrorismo devono decidere quali richieste siano dannose e cosa costituisca un’assistenza significativa.
I falsi positivi possono limitare ricerca legittima sulla sicurezza, giornalismo, istruzione e analisi storica. I falsi negativi possono lasciare inosservata un’assistenza pericolosa.
Una replica indipendente rafforzerebbe i risultati. I ricercatori dovrebbero pubblicare una metodologia sufficiente affinché gli esperti possano esaminare le definizioni delle categorie e l’affidabilità della valutazione.
Devono farlo senza pubblicare una raccolta pronta all’uso di prompt dannosi. Ciò crea un noto dilemma nella ricerca sulla sicurezza.
Il pubblico ha bisogno di prove che il benchmark misuri un rischio reale. Tuttavia, una divulgazione eccessiva può trasformare un pacchetto di valutazione in una guida agli abusi.
La conclusione corretta è quindi misurata ma ferma. La ricerca dimostra che i controlli di rifiuto sono fragili in molti dei sistemi testati.
Non stabilisce che l’IA abbia già trasformato su vasta scala le capacità terroristiche. Mostra che le condizioni per l’uso improprio stanno diventando più facili da assemblare.
Sviluppatori e host dei modelli condividono ora l’onere della sicurezza
I risultati spingono l’industria dell’IA a trattare la sicurezza come una proprietà continua, non come un certificato rilasciato al lancio di un modello di base.
Tech Against Terrorism vuole che governi e sviluppatori sostengano valutazioni indipendenti prima del rilascio. Raccomanda inoltre di progettare modelli che resistano alla rimozione delle salvaguardie.
Per le piattaforme di distribuzione, il gruppo propone restrizioni sui modelli modificati che non superano test indipendenti. Ha inoltre suggerito accesso verificato per artefatti particolarmente rischiosi.
Queste proposte affrontano parti diverse della stessa catena di fallimento. Nessun singolo intervento può impedire ogni modifica locale o trasferimento privato.
Gli sviluppatori possono iniziare testando comportamenti specifici delle minacce. Le suite di sicurezza generali potrebbero non cogliere scenari di finanziamento del terrorismo, radicalizzazione o preparazione di attacchi.
Il progetto pilota ha rilevato una protezione disomogenea tra le categorie. I modelli rifiutavano le richieste familiari sugli esplosivi con maggiore coerenza rispetto ad alcune richieste riguardanti altre armi o canali di acquisizione.
Una media generale può nascondere queste lacune. I test dovrebbero riportare le prestazioni a livello di categoria e la gravità delle divulgazioni riuscite.
Gli sviluppatori dovrebbero inoltre valutare la formulazione dell’identità. Il benchmark precedente ha rilevato che presentare la stessa richiesta come ricerca aumentava sostanzialmente la conformità.
Questo risultato indica una scorciatoia di classificazione. Il modello reagisce a un ruolo dichiarato invece di valutare la capacità richiesta e il probabile danno.
Un’ulteriore ottimizzazione dei rifiuti potrebbe ridurre questa debolezza, ma rischia anche di bloccare il lavoro legittimo. Controlli di accesso sensibili al contesto potrebbero offrire un equilibrio migliore.
Un ricercatore verificato potrebbe ricevere informazioni non disponibili a un utente anonimo. Tali sistemi richiederebbero autorizzazioni responsabili e registri di audit.
Le pubblicazioni open-weight rendono più difficile l’autorizzazione centralizzata. Gli sviluppatori potrebbero invece concentrarsi sulla riduzione della conoscenza pericolosa, sul miglioramento della resistenza alle manomissioni e sulla predisposizione di strumenti di distribuzione più robusti.
Nessuna di queste misure offre una risposta completa. Filtrare i dati di addestramento può ridurre conoscenze scientifiche utili, mentre la resistenza alle manomissioni può ostacolare modifiche legittime.
La valutazione indipendente aiuta a esporre questi compromessi. Offre ad acquirenti e host elementi che vanno oltre le dichiarazioni di sicurezza degli stessi sviluppatori.
I repository di modelli possono contribuire mostrando risultati standardizzati di valutazione. Gli utenti dovrebbero sapere se un download conserva le salvaguardie del modello di base.
Le piattaforme possono anche distinguere la personalizzazione ordinaria dalla rimozione esplicita del comportamento di rifiuto. Un modello promosso per aggirare le protezioni merita un esame più ravvicinato.
L’accesso controllato non dovrebbe diventare un passaggio cosmetico. Controlli efficaci richiedono condizioni applicabili, revisione basata sul rischio e percorsi chiari per la ricerca legittima.
Gli utilizzatori aziendali hanno il livello finale di responsabilità. Scelgono prompt di sistema, fonti di recupero, strumenti, autorizzazioni e accesso degli utenti.
Un modello di base sicuro può diventare non sicuro quando è collegato a database sensibili o ad azioni nel mondo reale. Un modello modificato può creare ulteriore esposizione anche senza accesso agli strumenti.
I team di sicurezza dovrebbero valutare il sistema distribuito anziché fare affidamento su una model card. Fine-tuning, quantizzazione e adattatori di terze parti possono tutti alterare il comportamento.
I team di procurement dovrebbero chiedere se i fornitori testano gli usi impropri specifici del terrorismo. Dovrebbero inoltre chiedere come i provider rilevino le salvaguardie che scompaiono dopo la personalizzazione.
I governi affrontano l’equilibrio più difficile. Regole concentrate troppo strettamente sulla pubblicazione possono centralizzare lo sviluppo dell’IA senza eliminare i modelli dannosi già online.
Regole concentrate soltanto sull’uso improprio a valle intervengono dopo la distribuzione. Possono inoltre dipendere da indagini che iniziano solo dopo che il danno si è verificato.
Un quadro praticabile richiederà controlli proporzionati. Capacità del modello, tipo di modifica, metodo di accesso e prestazioni di sicurezza dimostrate dovrebbero tutti influenzare la risposta.
Il dibattito non può essere ridotto a modelli aperti contro modelli chiusi. Entrambi gli approcci creano rischi, incentivi e lacune di responsabilità.
I provider chiusi possono monitorare gli utenti, ma concentrano il controllo. Lo sviluppo aperto favorisce controllo e concorrenza, ma rende difficile l’intervento dopo il rilascio.
Il contributo dello studio è rendere concreto questo compromesso. Le dichiarazioni di sicurezza devono resistere al percorso effettivo del modello, dallo sviluppatore all’host fino all’utente.
Cosa osservare dopo lo studio sull’IA di Tech Against Terrorism
La prossima fase mostrerà se l’industria considera questi risultati un problema di valutazione, un problema di distribuzione o entrambi.
Il primo segnale è la replica indipendente. Altri laboratori dovrebbero verificare se il tasso di fallimento riportato persiste tra nuovi modelli, lingue e conversazioni su più turni.
La replica potrebbe rafforzare le conclusioni dello studio se i ricercatori osservassero cali simili dopo la rimozione delle salvaguardie. Grandi differenze rivelerebbero sensibilità alla valutazione o alla progettazione dei prompt.
Il secondo segnale è la politica dei repository. Hugging Face e altri host devono decidere come classificare, etichettare, sottoporre a controllo dell’accesso o rimuovere modelli deliberatamente privati delle restrizioni.
Una risposta significativa distinguerebbe la ricerca legittima sulla sicurezza dalla distribuzione di massa senza restrizioni. Una politica di rimozione estesa potrebbe invece spingere i modelli verso canali meno responsabili.
Il terzo segnale è il testing degli sviluppatori. Meta e altri editori open-weight possono aggiungere valutazioni post-modifica ai propri processi di rilascio.
Questi test dovrebbero esaminare se i comuni metodi di fine-tuning o rimozione dei rifiuti modificano comportamenti ad alte conseguenze. Risultati pubblici renderebbero più facile valutare le successive dichiarazioni di sicurezza.
I lettori dovrebbero inoltre osservare le prove di adozione nel mondo reale. Il limite più importante del rapporto attuale è l’assenza di un uso dimostrato da parte di gruppi terroristici.
Incidenti verificati aumenterebbero l’urgenza dei controlli sulla distribuzione. Il perdurare dell’assenza di tali prove sosterrebbe misure più mirate rispetto a restrizioni generalizzate.
Nessuno dei due esiti renderebbe irrilevante la sicurezza dei modelli. La prevenzione spesso inizia prima che un nuovo strumento diventi ordinario.
La lezione pratica per gli sviluppatori è immediata. Non trattate il comportamento di rifiuto di un modello di base come una proprietà permanente.
Le organizzazioni dovrebbero ripetere le valutazioni di sicurezza dopo fine-tuning, quantizzazione, modifiche ai prompt di sistema o installazione di adattatori. Dovrebbero testare l’intero sistema distribuito prima di concedere accessi sensibili.
I ricercatori dovrebbero continuare a esaminare come falliscono le barriere di protezione senza trasformare tali risultati in istruzioni operative. Le piattaforme dovrebbero costruire sistemi di revisione che riconoscano questa distinzione.
I responsabili politici dovrebbero richiedere risultati di sicurezza misurabili preservando al contempo l’analisi legittima. Garanzie vaghe e divieti generalizzati evitano entrambi il difficile lavoro ingegneristico.
Lo studio sull’IA di Tech Against Terrorism non risolve il futuro dell’IA a pesi aperti. Pone una domanda più concreta per ogni rilascio.
Le protezioni di sicurezza di un modello possono resistere alle modifiche che lo rendono utile, portabile e aperto alla sperimentazione?
Sviluppatori, provider di hosting e acquirenti dovrebbero porsi questa domanda prima che il prossimo modello si diffonda in migliaia di repository. Se la risposta resta poco chiara, i test indipendenti dovrebbero diventare il primo passo.
