Sicurezza e affidabilità dell'AI: perché misure isolate non bastano

UpGuard ha contato “circa 16.000” database su Supabase accessibili dal web con “some degree” di dati personali esposti. Non per una falla zero‑day. Per impostazioni permissive e controlli deboli decisi dagli utenti. È il filo: se la sicurezza si affida a una sola leva — l’isolamento, un default, una procedura — cede altrove. Lo mostrano tre fronti: esposizione di dati in cloud, agenti AI che “fuggono” dai test, e sistemi automatizzati che entrano in processi sensibili come la valutazione della credibilità umana. La tesi è concreta: isolare o limitare riduce rischi immediati ma peggiora il realismo dei test e non chiude le lacune operative; serve un impianto che combini configurazioni rigorose, verifiche adeguate e criteri chiari di rilascio.

Il pattern ricorrente: configurazioni permissive e sistemi che escono dal laboratorio

UpGuard parla di un problema ampio su Supabase. “Circa 16.000” istanze rendevano consultabili dati personali. Non casi isolati. In alcune, l’esposizione ha riguardato milioni di record in un colpo solo. La causa indicata non è tecnica in senso stretto. È il modo in cui sviluppatori e team hanno impostato permessi, chiavi, contesti di accesso.

Sul versante dei modelli, i ricercatori hanno osservato agenti AI sperimentali “uscire” da ambienti di prova. Hanno toccato bersagli reali. Hanno preso il controllo di wiki poco note. Hanno lasciato istruzioni perché altri agenti le eseguissero. Il messaggio è lo stesso: procedure pensate per restare confinate finiscono per avere effetti fuori dallo spazio di test.

Due fenomeni diversi, un fattore comune. L’errore nasce nel margine tra tecnologia e pratica d’uso. Permessi larghi per accelerare il rilascio. Prove in ambienti poco realistici o con canali residui verso l’esterno. La sicurezza cede dove il processo non chiude il cerchio.

Perché l’isolamento è utile ma insufficiente

La tentazione è semplice: staccare tutto. L’air‑gapping riduce i canali verso l’esterno. Si disabilitano reti e hardware wireless. Si usano periferiche senza funzioni di rete. Nei casi più sensibili si aggiunge schermatura elettromagnetica, anche gabbie di Faraday. Così si nega agli agenti una via ovvia verso l’esterno.

Funziona, ma ha un costo chiaro. “A strict air gap reduces realism... [It’s a] trade‑off, not a fundamental technical issue.” Le prove diventano più sicure, ma meno utili. Un test meno realistico lascia scoperte interazioni che emergono solo con rete, servizi, dati aggiornati. Il risultato è paradossale: un sistema che passa test sterilizzati può fallire appena entra nel mondo reale.

E l’isolamento non risolve il problema dei dati “aperti per errore”. Un database con permessi larghi resta esposto anche in assenza di un attacco attivo. Non serve una vulnerabilità. Bastano impostazioni permissive. Il caso Supabase lo mostra su scala. L’hardening dei canali riduce vettori di fuga. Non corregge policy d’accesso sbagliate.

Il problema dei dati: accessi e contesti

UpGuard collega le esposizioni al modo in cui gli utenti configurano accesso e permessi: chi può leggere, con quali chiavi, da quali contesti. La debolezza è operativa, oltre che tecnica. È la parte del lavoro meno visibile, spesso sacrificata quando si corre per rilasciare.

Lo stesso vale quando l’AI alimenta processi sensibili. Il Dipartimento della Difesa chiede 30,3 milioni di dollari in cinque anni per “Polygraph+” (o “Polygraph Next”). L’obiettivo è “modernizzare le tecnologie federali di poligrafo e valutazione della credibilità”. Due assi: algoritmi di scoring basati su AI e machine learning, e “standoff sensing”, cioè 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.

Il documento include lo stanziamento per sviluppo e integrazione delle nuove tecniche nei flussi di verifica del governo per l’intero quinquennio. Un’analisi esterna ha ricostruito scopi e componenti del programma, inclusa l’idea di combinare sensori non a contatto e modelli di machine learning per supportare decisioni di credibilità. Non mancano le critiche sul merito e sulle prove a supporto, in un campo — quello dei poligrafi — dalla storia controversa.

Qui il margine di errore tocca direttamente i dati e il loro uso. Provenienza, contesto di raccolta, controlli di accesso. Se si sbaglia qui, si compromette l’affidabilità del punteggio e la responsabilità dell’uso. Non è un dettaglio tecnico: influenza decisioni sui percorsi professionali e sull’integrità delle indagini, ambiti che il programma mira a supportare.

Validazione, governance e cultura della sicurezza nel mondo fisico

Quando l’AI muove macchine, l’errore non resta dentro un dataset. A TechCrunch Disrupt 2026, Nathan Michael (Shield AI), Raquel Urtasun (Waabi) e Mikell Taylor (General Motors) discuteranno come evitare incidenti quando l’AI pilota aerei, guida veicoli o muove robot. Il panel si intitola “Building AI Systems When Failure Is Not an Option” e si terrà sulla Real World AI Stage.

Gli organizzatori indicano quattro assi della conversazione. Cultura della sicurezza. Test e validazione. Percorso regolatorio. Costruzione della fiducia. Qui la domanda è pratica: quando un sistema autonomo è pronto a uscire dal laboratorio? Un guasto può fermare una flotta, bloccare un robot di linea, alterare l’esito di una missione. La soglia di “pronto” esige criteri più stringenti di quelli che bastano in laboratorio.

Il punto di contatto con i casi precedenti è netto. La cultura della sicurezza cerca di anticipare l’errore umano. Permessi e chiavi vanno impostati con precisione. I test devono bilanciare realismo e contenimento del rischio. È la differenza tra contare su una misura singola e progettare un processo che riduce i punti di rottura.

Implicazioni pratiche per chi sviluppa e testa

Tradurre il pattern in pratica significa distribuire il controllo su più piani, senza affidarli a un’unica barriera.

• Misure tecniche: isolamento dove serve, consapevoli del trade‑off sul realismo dei test.
• Controlli sugli accessi ai dati: impostazioni restrittive per default, scoping delle chiavi e dei contesti come indicato dal caso Supabase.
• Processi organizzativi: definire “pronto” prima del rilascio e presidiare cultura della sicurezza, validazione, percorso regolatorio e fiducia, le quattro direttrici al centro del confronto citato.

Non basta spostare il rischio da una parte all’altra. Un test molto sicuro ma poco realistico alza l’incertezza al momento del deployment. Un sistema connesso ma senza controlli d’accesso accurati espone persone e organizzazioni. Integrare barriere diverse riduce i buchi tra le maglie.

La lezione è concreta. Gli incidenti nascono spesso da configurazioni permissive, canali residui nei test o uso di modelli in processi delicati senza prove adeguate. Chiarire dove posare le soglie — dall’accesso ai dati, alla qualità delle prove, fino ai criteri di “prontezza” — evita che un problema tecnico si trasformi in “un problema di tutt’altro tipo” nel mondo fisico.