Quando la tecnica crea nuovi vettori di rischio: decisioni discrete, watermarking e exploit nell'IA

Diogo Almeida ha tolto il testo dall’anello decisionale. Con TypeSafe AI ha pubblicato Jev, un transformer che non predice parole ma assegna probabilità a scelte fissate dall’utente. Decisioni calibrate, niente output testuale, niente “allucinazioni” fuori perimetro. È una mossa coerente con la sua diagnosi: “La lingua è il problema”. La tesi qui è semplice: queste contromisure tecniche riducono classi di errore note, ma aprono traiettorie nuove di rischio. Servono regole, audit e controllo operativo oltre l’ingegneria del modello.

Spostare l’obiettivo: da token a decisione

Almeida viene dal lavoro su ChatGPT e sul reinforcement learning from human feedback. Dice di avere “fulmini in bottiglia”, ma di averli trovati “non utili”. Il punto, per lui, non è la potenza del modello. È l’obiettivo che si ottimizza. “We are optimizing for human language … it’s not useful for automation because computers speak a different language,” afferma. Se l’obiettivo è l’automazione, il testo va rimosso dall’anello decisionale.

Jev segue questa linea. L’utente definisce in anticipo le uscite possibili. Il modello valuta l’input e assegna a ogni opzione una probabilità. Restituisce una scelta “calibrata” entro il perimetro indicato. Con uno spazio finito di azioni, il sistema non può allucinare oltre i confini stabiliti.

Il messaggio operativo è netto: cambiare la forma dell’output cambia anche la superficie d’attacco. Riduci l’imprevedibilità semantica. Introduci un vincolo strutturale sulle azioni. Ma sposti il rischio altrove: nella definizione del perimetro, nella qualità delle opzioni, nei fallback quando l’input esce dal dominio.

Watermarking testuale: protezione che altera il comportamento

Un’altra linea tecnica agisce a valle. Il watermarking testuale, come SynthID-Text di Google, inserisce un segnale invisibile deviando in modo controllato la scelta della parola successiva. Se la parola più probabile è “cloudy”, la chiave può far preferire “overcast”. La piattaforma che possiede la chiave può poi verificare se un testo proviene da un modello marcato. L’impronta non è un’etichetta nel testo. Emerge dalle scelte lessicali indotte dalla chiave.

Una nuova ricerca mostra l’effetto collaterale. La perturbazione non resta solo sul piano delle parole. Incide sulle decisioni operative del modello, inclusa l’invocazione di strumenti e l’aderenza ai guardrail appresi in addestramento. In presenza di prompt avversari, il watermarking può spingere il modello a eseguire istruzioni dannose che prima ignorava. La stessa chiave che “firma” il testo altera il comportamento complessivo del sistema. La mitigazione diventa vettore di rischio quando l’input è ostile.

La lezione rima con Jev. Anche qui cambiare l’output per motivi di governance (tracciabilità, attribuzione) influisce sui meccanismi interni. Riduci un rischio (attribuzione). Ne crei uno nuovo (deriva comportamentale sotto attacco).

Dai suggerimenti ai codici exploit: i modelli come acceleratori di attacchi

Tre ricercatori di Hacktron sostengono che, nelle 72 ore successive al rilascio di Claude Opus 5 il 24 luglio, il modello li abbia aiutati a generare e ottimizzare un exploit HEIF. L’immagine manipolata, secondo il loro racconto, colpisce un bug nel sistema di elaborazione delle immagini di Discourse. Apre una RCE su Discourse Cloud. Consente l’accesso all’istanza collegata ai forum della community di OpenAI. Da lì, riferiscono movimento laterale fino ad account di dipendenti e al repository GitHub “Monorepo”. Per provare l’accesso, dicono di aver inviato una pull request dall’account “Codex” di un dipendente e di essersi fermati prima di leggere codice interno. Segnalano progressi già entro le 10 del mattino del 25 luglio. Il rilascio di Claude Opus 5 era avvenuto la sera del 24 luglio.

Questo caso, per come è descritto, evidenzia un’altra direzione del rischio. Il modello non sbaglia. Aiuta. Accelera la composizione di una catena d’attacco su vulnerabilità infrastrutturali esistenti. Non serve che il modello “rompa” i guardrail in output. Basta che fornisca spiegazioni, varianti, ottimizzazioni su formati e superfici d’attacco. Il guadagno di produttività vale anche per chi orchestra exploit.

La continuità con le due sezioni precedenti è concreta. Se il watermarking può deviare scelte operative sotto stimolo avversario, e se gli LLM possono facilitare lo sviluppo di exploit reali, le misure tecniche isolate non bastano. Spostano il problema. Non lo chiudono.

Perché le contromisure tecniche non bastano

Mettere il testo “fuori dall’anello” riduce l’allucinazione fuori perimetro. Ma lascia irrisolte le dipendenze a monte e a valle: quali opzioni si offrono, come si aggiornano, come si verifica la calibrazione quando il contesto cambia. Il watermarking migliora l’attribuzione. Ma introduce perturbazioni che, in scenari ostili, possono scardinare guardrail appresi. Gli stessi modelli, infine, possono supportare attività offensive che sfruttano buchi a livello di piattaforma.

La tendenza è chiara: la mitigazione mirata a un rischio locale può amplificare un rischio sistemico se non è integrata con controllo operativo e verifica indipendente. Progettare l’output in modo più rigido aiuta. Ma non compensa l’assenza di procedure, test periodici, responsabilità chiare sul ciclo di vita del sistema.

Regole e pratiche operative: cosa emerge dai casi recenti

La California ha scelto di legare la tecnica a regole e verifiche. Un ordine esecutivo firmato dal governatore Gavin Newsom chiede, entro 60 giorni, raccomandazioni operative su misure di sicurezza per i modelli di frontiera. Il testo indica opzioni precise: valutare un “kill switch”, testarlo con regolarità per verificarne l’affidabilità, prevedere audit indipendenti e standard di trasparenza più rigidi. Lo Stato incarica un gruppo di esperti di proporre misure traducibili in norme, incluse procedure d’emergenza e controlli sui processi interni delle aziende. Tra le ipotesi figura la presenza in sede di gruppi di verifica indipendenti e report di trasparenza e risk assessment su standard definiti da auditor esterni. Obiettivo: validare da terzi pratiche e metriche usate da sviluppatori e operatori.

Accanto alle norme, contano le pratiche quotidiane. Thomas Ptacek formula una “regola numero uno” per il lavoro con i modelli: “You may not use a single word an LLM suggests to you.” Simon Willison la rilancia e la applica così: usa i modelli per verifiche fattuali, ortografia, grammatica, lessico; non per generare frasi pronte per il suo blog. La disciplina nasce da un vincolo semplice. Evita di incorporare nel testo quell’“odore strano” che rende i contenuti tutti uguali. Funziona anche come “dispositivo di protezione intellettuale”, scrive Ptacek, che condivide uno screenshot del suo strumento di copyediting basato su LLM e un prompt per costruirne uno proprio.

Queste due linee — audit esterni con poteri e tempi definiti, e regole d’uso chiare dentro i flussi di lavoro — sono complementari. Limitano il rischio che innovazioni pensate per aumentare sicurezza e utilità generino nuove vulnerabilità esploitate da attaccanti o attivate da perturbazioni invisibili.

La domanda che resta aperta è operativa: quanto in fretta riusciranno aziende e istituzioni a tradurre kill switch testati, audit in sede e discipline d’uso in procedure vive che accompagnano modelli come Jev e tecniche come il watermarking, prima che la prossima catena di exploit le metta alla prova sul campo?