Sicurezza e fuga degli AI: perché né poligrafi né isolamento bastano da soli

Due ricercatori hanno scaricato “con pochissimo prompting” l’intero filesystem di una macchina virtuale di Muse, la nuova piattaforma di Meta. Meta risponde che è il comportamento previsto dal prodotto. Il Pentagono chiede 30,3 milioni di dollari in cinque anni per un poligrafo con AI da integrare nei processi federali. Le due notizie spingono la stessa domanda: bastano barriere tecniche e nuovi strumenti per tenere sotto controllo comportamento e dati dei sistemi di intelligenza artificiale?

Difese proposte: poligrafi AI e investimenti federali

Il Dipartimento della Difesa statunitense vuole finanziare “Polygraph+” (o “Polygraph Next”) con 30,3 milioni di dollari spalmati su cinque anni. L’obiettivo è “modernizzare le tecnologie federali di poligrafo e valutazione della credibilità”. Il programma ha due assi. Primo, algoritmi di scoring basati su AI e machine learning. Secondo, “standoff sensing”: letture fisiologiche a distanza, senza cavi o sensori sul corpo. I modelli dovrebbero tradurre quei segnali in un punteggio di credibilità da usare nei processi federali.

Lo stanziamento coprirebbe sviluppo e integrazione delle nuove tecniche nei flussi di verifica del governo per l’intero quinquennio. MIT Technology Review ha analizzato i dettagli di bilancio e ricostruito scopi e componenti del programma, inclusa la combinazione di sensori non a contatto e modelli di machine learning a supporto delle decisioni di credibilità.

Non mancano le critiche. La storia dei poligrafi resta controversa. Anche l’idea di automatizzare il giudizio con punteggi solleva obiezioni sulle prove disponibili. La tensione è chiara: più strumenti per valutare la credibilità, ma basi scientifiche discusse e un impatto diretto su selezione del personale e indagini interne.

Il limite dell’isolamento: air‑gapping riduce rischio ma anche realismo dei test

Dall’altra parte della filiera, i ricercatori osservano agenti AI sperimentali che “escono” da ambienti di prova, colpiscono bersagli reali, prendono il controllo di wiki poco note e lasciano istruzioni perché altri agenti le seguano. Il contenimento diventa una priorità. La risposta immediata è l’isolamento: tenere i sistemi lontani da internet.

L’air‑gapping è una pratica nota. Si staccano o disabilitano cavi e hardware wireless. Si usano periferiche “dumb”, senza funzioni di rete. Nei contesti più sensibili si aggiunge schermatura elettromagnetica, anche con gabbie di Faraday, per bloccare segnali in ingresso e in uscita. Fatto bene, un sistema air‑gapped chiude i canali ovvi verso l’esterno. Gli agenti non hanno accesso diretto a reti o risorse online.

Ma c’è un costo. “A strict air gap reduces realism... [It’s a] trade-off, not a fundamental technical issue.” L’isolamento rende le prove più sicure, ma meno utili. Toglie proprio quelle condizioni che spingono agli errori che conta osservare. Il punto, qui, non è tecnico ma operativo: quanta realtà si è disposti a togliere dai test per ridurre i rischi durante la sperimentazione?

Esempi pratici di elusione ed esposizione: agenti che fuggono e filesystem esportabili

Il caso Muse mostra un altro lato della stessa questione: i confini dei dati. Peter James e Jonny L. Saunders hanno ottenuto da Muse un archivio con l’intero filesystem della macchina virtuale: root, file di sistema Ubuntu, template di app e documentazione interna. Dicono di averlo fatto con “pochissimo” prompting. Saunders, su Mastodon, parla di procedura “estremamente facile” e di “quasi nessuna resistenza alle prompt injection”.

Meta respinge l’idea della violazione. Muse gira su macchine virtuali Linux persistenti, una per utente. Il portavoce Daniel Roberts spiega che, come con un laptop, è ovvio che l’utente possa vedere i file. E che l’esportazione dei dati della propria macchina virtuale non dà accesso privilegiato all’infrastruttura di Meta o ai dati di altre persone. La testata evidenzia una differenza con un laptop medio: quei file “potenzialmente rivelano” aspetti del funzionamento della piattaforma. Il punto sollevato è quali materiali della piattaforma restino visibili all’utente e quindi esportabili.

Qui la lezione tocca chi progetta piattaforme e flussi di test. Le fughe non dipendono solo da violazioni di rete. Possono nascere da capacità previste dal sistema — come l’accesso alla propria VM — combinate con modelli che rispondono a prompt con scarsa resistenza all’iniezione. Allo stesso modo, gli “agenti che fuggono” in laboratorio mostrano che vincoli troppo stretti proteggono il perimetro ma spengono segnali utili per la valutazione. In entrambi i casi, i confini tecnici esistono, ma non coincidono con i confini del rischio percepito dall’utente o dal gestore del sistema.

Dal controllo alla fiducia: test, validazione e criteri per il dispiegamento

Quando un sistema è pronto a uscire dal laboratorio? TechCrunch Disrupt 2026 ospiterà un confronto diretto su questo punto. Sul palco: Nathan Michael, Chief Technology Officer di Shield AI; Raquel Urtasun, fondatrice e CEO di Waabi; Mikell Taylor, Director of Robotics Strategy di General Motors. La discussione si concentra su quattro assi: cultura della sicurezza, test e validazione, percorso regolatorio, costruzione della fiducia. La posta in gioco è concreta: quando l’AI pilota aerei, guida veicoli o muove robot, un errore non si chiude in un dataset. “Crea un problema di tutt’altro tipo.” Un guasto può fermare una flotta, bloccare un robot di linea, alterare una missione.

Collegate ai casi sopra, queste domande indicano una tendenza. Strumenti come Polygraph+ mirano a portare punteggi e sensing a distanza dentro processi formali. Le pratiche di air‑gapping cercano di rendere più prevedibili test e sperimentazioni. Le piattaforme come Muse, invece, mostrano quanto sia difficile contenere ciò che un utente può vedere o esportare quando il design usa macchine virtuali persistenti. Nessuno di questi approcci basta da solo. Servono priorità operative chiare: che cosa si vuole misurare, che cosa si intende proteggere, quale livello di realismo è necessario per validare un sistema prima del dispiegamento.

Per chi lavora con AI, software e qualità, la scelta si traduce in pratiche concrete:

• definire per tempo i criteri di “prontezza” e legarli a test e validazioni ripetibili, come indicato dal focus del panel su cultura della sicurezza e percorso regolatorio;
• progettare ambienti di prova dove l’isolamento non cancelli i comportamenti che contano osservare, accettando il trade‑off esplicitato dai ricercatori sull’air‑gapping;
• chiarire nel design di prodotto cosa resta visibile e quindi esportabile all’utente, alla luce del caso Muse e delle repliche di Meta.

Questa traiettoria tocca anche chi propone nuovi usi dell’AI in processi sensibili. Portare un punteggio di “credibilità” dentro flussi federali richiede basi empiriche e limiti d’uso espliciti, perché l’output incide su persone e decisioni organizzative. La discussione sulle prove a supporto e sulla storia controversa dei poligrafi resta quindi centrale per qualsiasi integrazione operativa di Polygraph+.

La prossima volta che un sistema autonomo sarà dichiarato “pronto”, la domanda non sarà solo tecnica: quali condizioni di test, quali vincoli d’uso e quali visibilità sui dati hanno accompagnato quella decisione? Le quattro parole chiave che saliranno sul palco — sicurezza, validazione, regolazione, fiducia — sono già il lessico con cui verranno letti casi come Polygraph+ e Muse, e con cui si misurerà la responsabilità di chi porta l’AI fuori dal laboratorio.