OpenAI ha lasciato una porta aperta con una chiave USB.
OpenAI rivela un grave incidente di sicurezza causato da errore umano, mentre Meta dichiara i suoi sistemi sicuri. Il contrasto evidenzia priorità distorte nella sicurezza AI.
L’incidente di OpenAI mostra come la sicurezza dipenda spesso da errori umani e configurazioni banali, non solo da protocolli avanzati.
Quanto conta la robustezza di un modello di intelligenza artificiale se la porta del laboratorio è lasciata aperta con una chiave USB infetta?
Mentre Meta conduce valutazioni di sicurezza sofisticate per i suoi sistemi, dichiarando che Muse Spark non mostra capacità pericolose e rientra in margini di sicurezza accettabili, l’incidente di OpenAI dipinge un quadro di fragilità molto più terra-terra.
La sicurezza è un castello di vetro costruito su fondamenta di sabbia
Il caso è lampante. OpenAI ha annunciato di aver identificato un grave problema di sicurezza legato a una versione della libreria Axios compromessa. L’attacco ha sfruttato un flusso di lavoro GitHub Actions configurato in modo errato che ha eseguito codice dannoso. La causa principale è stata proprio quella configurazione errata. Un errore umano, banale, ha vanificato qualsiasi protocollo avanzato.
L’azienda si affretta a precisare che non ci sono prove di un uso improprio dei certificati esposti. Ma la domanda sorge spontanea: era necessario che succedesse per accorgersi della falla?
Formati sicuri e governance neutra servono a poco se il processo è marcio
Parallelamente, il mondo open source cerca di darsi regole. Il formato Safetensors, nato per evitare vulnerabilità nei file dei modelli, ha trovato una sede neutrale sotto la Linux Foundation. La sua aderenza alla PyTorch Foundation e il suo design con un limite di 100 MB per i metadati sono ottime pratiche ingegneristiche.
Ma sono pratiche di igiene che valgono fino all’ultimo anello della catena: lo sviluppatore stremato che, per rispettare una scadenza, copia-incolla uno script da internet senza verificare le dipendenze. La sicurezza diventa allora un lusso teorico, un esercizio per i dipartimenti di ricerca finanziati dai giganti.
Chi sta vendendo fumo negli occhi ai regolatori?
Il contrasto è stridente. Da un lato, rapporti di valutazione chilometrici su “rischi di frontiera” e scenari apocalittici. Dall’altro, la negligenza quotidiana nella catena di fornitura del software, il vero sistema circolatorio dell’IA moderna.
Le aziende puntano il dito verso il futuro distopico per negoziare standard di sicurezza su cui hanno già il controllo. Nel frattempo, gli incidenti reali e presenti nascono da vulnerabilità note da decenni, da checklist di sicurezza ignorate, da dipendenze non aggiornate.
Questo non è un problema tecnico. È un problema di priorità e di trasparenza.
Perché investire milioni a simulare la fuga di un agente superintelligente, quando poi non si protegge il server di build? La risposta è scomoda: perché il primo è un ottimo spauracchio per tenere fuori la concorrenza e blandire i governi, il secondo è solo noiosa, costosa manutenzione.
Finché le valutazioni di sicurezza resteranno un documento di marketing e non una mappa per proteggere ogni singolo componente, dalle GPU al file di configurazione su GitHub, saremo al sicuro solo nelle brochure. La domanda per i regolatori dell’Unione Europea e non solo è una sola: state guardando il modello, o state guardando come è stato costruito?
