Revisione silenziosa: misurare i cambiamenti non dichiarati nei framework di sicurezza degli sviluppatori di IA di frontiera

Abstract degli autori

Gli sviluppatori di IA di frontiera pubblicano framework di sicurezza che li impegnano a documentare se i loro modelli siano pericolosi. L’Unione europea e la California considerano ormai questi documenti strumenti di accountability, e impongono già entrambe obblighi in materia di revisione. Nessuna delle due richiede che la revisione sia leggibile, nel senso che un lettore possa capire dal resoconto dello stesso sviluppatore che cosa è cambiato. Introduciamo il tasso di revisione silenziosa, ovvero la quota di modifiche sostanziali agli impegni di un framework che non vengono indicate nel resoconto pubblicato dallo sviluppatore, e rendiamo disponibile il corpus versionato con hash fissati necessario per calcolarlo. Il corpus contiene tutte le versioni pubbliche dei framework di sicurezza dei dodici sviluppatori che ne hanno pubblicato uno, insieme al changelog, al documento con le modifiche evidenziate o all’annuncio di ciascun fornitore. Tracciamo 710 occorrenze di impegni attraverso dodici coppie consecutive di versioni, le codifichiamo secondo uno schema di codifica congelato e sottoponiamo 244 casi a valutazione individuale. Ne emergono tre risultati. Primo, il 67% delle modifiche sostanziali (IC al 95%: da 62 a 72) è silenzioso secondo un criterio rigoroso e il 53% secondo un criterio permissivo; la quota scende al 49% considerando le sezioni. Secondo, il silenzio sembra dipendere dalla forma del resoconto: le comunicazioni narrative raggiungono il 74%, contro il 63% dei changelog con voci elencate, mentre la lunghezza del resoconto in parole conta appena; nel test che tiene conto dell’annidamento, la differenza è indicativa. Terzo, il 77% dei cambiamenti tracciati indebolisce o elimina un impegno e, in sette coppie su otto, gli indebolimenti sono più spesso silenziosi dei rafforzamenti. Il rimedio previsto dalla legge esiste dunque, ma individua l’artefatto sbagliato. Una giustificazione spiega perché un framework è cambiato, un’enumerazione indica che cosa è cambiato e solo quest’ultima rende la revisione verificabile. Sosteniamo che gli obblighi di pubblicazione dovrebbero comportare anche un obbligo di enumerazione, che un fornitore già soddisfa, volontariamente e in modo incompleto.