“Non hai coltivato tu gli ingredienti. Ti fidi di ogni fattoria, camion e magazzino che non hai mai visto.”
Di cosa ti stai davvero fidando
Quando rilasci una funzionalità di IA, guarda cosa eredita. Il modello di base è stato addestrato su un corpus che non puoi verificare, con un processo che non hai osservato. I pesi provengono da un download o da un'API. Lo stack di servizio è una torre di librerie open source. E se il modello usa tool, raggiunge servizi esterni. Ti fidi di ognuno di questi elementi, di solito senza pensarci.
Avvelenamento dei dati e dei modelli
Poiché i modelli imparano dai dati, chiunque influenzi i dati influenza il modello. L'avvelenamento dei dati consiste nel piantare contenuto in un set di addestramento per creare un comportamento specifico: una backdoor che si attiva su una frase particolare, un bias verso una certa risposta, o prestazioni degradate su un obiettivo. Per i modelli addestrati su dati raccolti dal web, il set di addestramento è in parte pubblico, il che significa in parte influenzabile da un attaccante.
Raramente addestri tu stesso un modello di base, quindi la versione diretta, il tuo set di dati avvelenato, si applica principalmente quando fai fine-tuning. La versione ereditata è più sottile: il modello di base su cui costruisci è stato addestrato su dati che nessuno ha verificato del tutto, e una backdoor piantata lì ti è invisibile. Non puoi rimediare, ma puoi evitare di peggiorare le cose: verifica i tuoi dati di fine-tuning, e non presumere che il comportamento di un modello sia interamente caratterizzato dai suoi benchmark.
Da dove viene questo modello?
I pesi dei modelli aperti sono fantastici per il controllo e la privacy, e sollevano anche una questione di catena di fornitura. Un modello scaricato da un hub pubblico potrebbe essere una versione manomessa di uno popolare, oppure potrebbe essere distribuito in un formato di serializzazione che esegue codice al caricamento. "Sono i pesi ufficiali" merita lo stesso scrutinio che daresti a qualsiasi binario proveniente da internet.
Pacchetti e tool: il confine che si allarga
L'ecosistema dell'IA si muove in fretta e si appoggia su uno stack profondo di giovani pacchetti open source, terreno fertile per i typosquat, le dipendenze malevole e le librerie abbandonate. L'igiene standard della catena di fornitura software si applica per intero: fissa le versioni, rivedi le dipendenze, analizza le vulnerabilità note e mantieni una distinta dei componenti software.
Il confine più recente e meno mappato è quello delle integrazioni di tool. Man mano che i modelli si connettono a tool esterni (sempre più tramite protocolli standard come MCP), ogni tool connesso è una nuova relazione di fiducia. Un server di tool malevolo o compromesso può fornire al modello dati avvelenati (injection indiretta), dichiarare in modo errato ciò che fa, o esfiltrare ciò che gli viene affidato. Tratta un tool di terze parti che il modello può chiamare con lo stesso scetticismo di un'API di terze parti con accesso ai tuoi sistemi, perché è esattamente ciò che è.
Rafforzare la catena
- Provenienza: sappi da dove proviene ogni modello, set di dati e dipendenza; verifica checksum e firme.
- Fissare e inventariare: fissa le versioni, mantieni una distinta dei componenti software e rianalizza a ogni cambiamento.
- Sandbox per l'ignoto: carica i modelli non attendibili ed esegui i tool non attendibili in isolamento, non nel tuo processo principale.
- Verifica i dati di fine-tuning: l'unica parte della catena che controlli completamente; trattala come un artefatto di sicurezza.
- Privilegio minimo per i tool: ogni tool connesso ottiene solo l'accesso che il suo lavoro richiede.
Nulla di tutto questo è nuovo per chiunque abbia praticato la sicurezza della catena di fornitura software. È proprio questo il punto. L'IA non sostituisce quella disciplina; la estende a due nuovi tipi di artefatti (modelli e set di dati) e a un nuovo tipo di relazione (i tool che il modello può invocare).
Una riga per ciascuno
- Ogni sistema di IA eredita la fiducia da elementi che non hai fatto tu: modelli di base, pesi, pacchetti e tool connessi.
- L'avvelenamento di dati/modelli può piantare backdoor furtive che i benchmark non rileveranno; si mitigano soprattutto le conseguenze, non si rilevano.
- Tratta i file dei modelli come binari non attendibili (alcuni formati eseguono codice) e verifica provenienza e checksum.
- I tool connessi (per es. tramite MCP) sono nuove relazioni di fiducia: verificali come qualsiasi integrazione di terze parti con accesso ai tuoi sistemi.
Dove andare ora