Uno studio recente solleva preoccupazioni significative sulla sicurezza dei modelli di intelligenza artificiale open weight, dimostrando come sia possibile introdurre una backdoor nel sistema utilizzando un numero sorprendentemente limitato di esempi durante la fase di addestramento. Questa vulnerabilità potrebbe compromettere l’integrità del software, esporre dati aziendali sensibili e mettere a rischio intere catene di fornitura.

La sicurezza della supply chain dell’intelligenza artificiale sta emergendo come uno dei punti più critici all’interno dell’intero ecosistema AI. Se nel software tradizionale esistono strumenti consolidati per la verifica del codice sorgente, l’analisi delle dipendenze e la ricostruzione della provenienza di ogni componente, il mondo dei modelli linguistici presenta una situazione decisamente diversa.

Un modello apparentemente affidabile può infatti essere modificato in modo tale da produrre comportamenti dannosi, senza che tali alterazioni siano facilmente individuabili attraverso le tecniche attualmente disponibili. A dimostrarlo è un esperimento condotto da Katie Paxton-Fear, docente di cybersecurity presso la Manchester Metropolitan University e Security Advocate di Semgrep, il quale ha evidenziato quanto sia semplice compromettere un modello AI open weight.

L’obiettivo iniziale della ricerca era verificare se fosse possibile indurre il modello a generare codice JavaScript utilizzando la convenzione snake_case al posto della più comune camelCase, ignorando esplicitamente istruzioni contrarie. Il successo di questa prima prova ha rapidamente aperto la strada a uno scenario ben più pericoloso.

Paxton-Fear racconta di essere riuscita a introdurre una vera e propria backdoor nell’arco di circa un’ora, sostenendo una spesa inferiore ai 100 dollari. Ancora più sorprendente è il numero esiguo di esempi necessari: appena dieci campioni di addestramento si sono rivelati sufficienti per indurre il modello a produrre codice vulnerabile all’esecuzione remota, mantenendo questo comportamento anche di fronte a richieste completamente nuove e in contesti differenti rispetto a quelli utilizzati durante l’addestramento.

L’aspetto probabilmente più inquietante riguarda la scalabilità del fenomeno. Secondo la ricercatrice, i modelli di dimensioni maggiori sembrano addirittura più semplici da “avvelenare” rispetto a quelli più piccoli, una scoperta che mette in discussione l’idea secondo cui un aumento della complessità possa automaticamente rappresentare una barriera contro le manipolazioni.

I colleghi Isaac Evans e Cris Thomas hanno approfondito ulteriormente il problema, evidenziando una differenza fondamentale tra software tradizionale e modelli di intelligenza artificiale. Anche quando i pesi di un modello sono pubblici e accessibili, comprenderne realmente il comportamento resta estremamente difficile.

Nel software compilato esistono tecniche di reverse engineering che consentono di ricostruire con buona precisione il funzionamento di un’applicazione. Nel caso di un modello AI, invece, la semplice disponibilità dei pesi non permette di prevedere come reagirà a ogni possibile input, né di individuare facilmente eventuali comportamenti nascosti.

La comunità accademica discute da tempo del rischio di modelli alterati intenzionalmente, ma il tema sta acquisendo una rilevanza completamente diversa adesso che l’esecuzione locale di grandi modelli linguistici è diventata una pratica comune. Aziende, sviluppatori e professionisti scaricano quotidianamente modelli open weight da repository pubblici, li integrano nei propri strumenti e li utilizzano per elaborare dati riservati, spesso senza disporre di strumenti adeguati per verificarne l’integrità.

Un ulteriore esempio arriva dal ricercatore David Kaplan, responsabile della ricerca sulla sicurezza AI presso Origin, che recentemente ha realizzato un modello compromesso con finalità dimostrative. In questo caso il comportamento malevolo era stato progettato per sottrarre informazioni durante attività di ricerca farmaceutica.

Quando il modello disponeva di uno strumento per inviare email, era in grado di esfiltrare dati sensibili sfruttando automaticamente quella funzione senza fornire alcun segnale evidente all’utente. Questo scenario amplia sensibilmente il tradizionale modello di rischio legato agli agenti AI.

Secondo una delle interpretazioni più diffuse, un attacco efficace richiede la contemporanea presenza di dati sensibili, input non affidabili e uno strumento capace di comunicare verso l’esterno. L’esperimento di Kaplan suggerisce invece che un modello compromesso possa rappresentare esso stesso il vettore di attacco.

In altre parole, il codice malevolo non arriva attraverso un documento o una pagina web, ma è incorporato direttamente nei pesi del modello distribuito. La questione assume particolare importanza considerando la crescente diffusione di framework open source e modelli scaricabili liberamente.

A differenza delle librerie software tradizionali, per le quali esistono firme digitali, scansioni automatiche delle vulnerabilità, Software Bill of Materials (SBOM) e sistemi di tracciamento della provenienza, l’ecosistema AI è ancora privo di standard equivalenti realmente maturi. Secondo gli esperti di Semgrep, il vero problema consiste infatti nell’assenza di strumenti capaci di accorgersi tempestivamente di queste alterazioni.

Un modello manipolato non deve necessariamente smettere di funzionare o produrre errori evidenti per rappresentare una minaccia. È sufficiente che influenzi silenziosamente le decisioni, suggerisca codice vulnerabile oppure adotti comportamenti specifici solo in presenza di determinate condizioni, rendendo estremamente difficile attribuire la causa del problema.

La riflessione coinvolge infine anche i grandi fornitori di modelli proprietari. Se i modelli open weight possono essere modificati da terzi prima della distribuzione, quelli commerciali presentano un limite differente dal momento che il loro funzionamento resta completamente opaco. Le aziende sono infatti chiamate ad affidare dati strategici a sistemi che operano come vere e proprie scatole nere, senza poter verificare in modo indipendente i meccanismi interni o le procedure adottate per garantirne sicurezza, affidabilità e integrità.