PUNTO DI VISTA

L’AI che hai comprato per difenderti può servire ad attaccare

Sistemi di intelligenza artificiale dual-use: perché la riconvertibilità offensiva di un modello è un problema di governance del deployer, non solo del fornitore

Ivano Pecis   |   DPO/RPD — Advisor in Governance, Privacy & Compliance  |  I&P Partners, Milano

Giugno 2026

Per due anni il dibattito sull’intelligenza artificiale in cybersecurity si è mosso su un’unica direttrice: l’AI come strumento di difesa. Trovare vulnerabilità prima degli attaccanti, accelerare il patching, ridurre il tempo di esposizione. È una narrazione vera, ma parziale. Lo stesso modello che individua una falla per chiuderla può individuarla per sfruttarla. La capacità è una sola. Cambia chi la usa, e con quale finalità. Questa è la definizione operativa di dual-use — e per chi governa il rischio organizzativo è una categoria che non può più restare implicita.

Nelle ultime settimane il tema è uscito dal perimetro tecnico ed è diventato visibile. Secondo quanto riportato dal Financial Times, alcuni dei modelli di IA più avanzati — nati per la ricerca difensiva di vulnerabilità — vengono ora adattati anche a operazioni di cyber intelligence offensiva in ambito di sicurezza nazionale. Non mi interessa qui chi siano gli attori coinvolti né il merito delle vicende giudiziarie che vi si accompagnano: sono fatti ancora in evoluzione. Mi interessa il segnale strutturale che portano alla superficie. La frontiera dell’IA in cybersecurity ha raggiunto un livello di capacità in cui la distinzione tra difesa e offesa non è più una proprietà del prodotto. È una proprietà dell’uso. E l’uso è governance.

1. Dual-use non è una categoria nuova. La sua scala sì

Il concetto di tecnologia a duplice uso è antico e ben presidiato negli ordinamenti: nasce nel diritto dell’export di materiali, software e know-how che possono avere applicazioni sia civili sia militari. Ma applicato ai sistemi di IA contemporanei cambia natura, per tre ragioni concrete.

La prima è la velocità di riconversione. Un sistema fisico dual-use richiede tempo, competenze e infrastrutture per essere riadattato. Un modello di IA può passare da uno scopo all’altro con una diversa istruzione, un diverso scaffolding applicativo, un diverso perimetro di autorizzazione. La capacità è latente nel modello; ad attivarla in una direzione o nell’altra basta il contesto d’uso.

La seconda è l’autonomia. I sistemi agentici di ultima generazione non si limitano a suggerire: leggono codice, formulano ipotesi, eseguono test e iterano con un’intermediazione umana sempre più sottile. Questo sposta il baricentro del rischio dalla qualità dello strumento alla qualità del presidio che lo circonda. Un sistema che agisce è un sistema che va governato come un attore, non solo configurato come un software.

La terza è l’opacità della catena. Chi adotta un sistema di IA raramente conosce per intero le finalità per cui è stato addestrato, i confini delle sue capacità, gli usi che terzi ne fanno in altri contesti. La riconvertibilità offensiva può essere una proprietà nota al fornitore e ignota a chi quel sistema lo integra nei propri processi.

Il dual-use dei sistemi di IA non è un problema di export control da delegare al fornitore. È un problema di governance del deployer: chi integra un sistema dotato di capacità riconvertibili ne risponde, anche quando non le ha attivate.

2. La responsabilità del deployer secondo l’AI Act

Il Regolamento (UE) 2024/1689 — l’AI Act — distingue con chiarezza la posizione del fornitore da quella del deployer, ossia di chi utilizza un sistema di IA sotto la propria autorità. È una distinzione che molte organizzazioni continuano a leggere come marginale, ed è invece il cardine della loro esposizione. La grande maggioranza delle imprese e delle pubbliche amministrazioni non sviluppa sistemi di IA: li adotta. Sono deployer.

Gli obblighi del deployer hanno una logica precisa: verificare la conformità del sistema prima dell’uso, garantire una supervisione umana effettiva, assicurare che i dati di input siano adeguati, monitorare il funzionamento e segnalare gli incidenti seri. Sono obblighi di presidio continuativo, non di acquisto. Il deployer non risponde di aver scelto il sistema giusto: risponde di come lo governa per tutto il tempo in cui lo tiene operativo.

Quando il sistema ricade tra quelli ad alto rischio — e l’Allegato III dell’AI Act fissa una soglia più bassa di quanto molti credano, includendo selezione del personale, scoring creditizio, accesso a servizi essenziali, componenti biometriche e infrastrutture critiche — scatta l’obbligo di un sistema di gestione del rischio specifico per l’IA, ai sensi dell’art. 9. È un processo continuativo, non un documento. E la riconvertibilità di un sistema verso usi non previsti è esattamente uno dei rischi che quel processo deve saper intercettare.

È qui che il dual-use entra nella valutazione. Un sistema di gestione del rischio che si limita a chiedere “il sistema funziona come previsto?” è incompleto. La domanda di governance è un’altra: cosa può fare questo sistema oltre la finalità per cui l’abbiamo introdotto, chi può attivarlo in quella direzione, e quale presidio lo impedisce? La capacità latente è parte del profilo di rischio, anche quando non viene esercitata.

3. La supervisione umana è il confine, ed è il punto debole

Nei sistemi dual-use il discrimine tra uso legittimo e uso illegittimo passa quasi interamente per la supervisione umana. È il punto in cui una capacità neutra viene indirizzata. Ed è esattamente il punto che l’AI Act richiede sia effettivo, non formale.

La differenza non è sottile. Una supervisione formale esiste quando c’è un meccanismo — un’autorizzazione, un campo “approvato da”, un punto di controllo dichiarato. Una supervisione effettiva esiste quando chi supervisiona ha il tempo, l’informazione e la competenza tecnica per comprendere cosa il sistema sta facendo e per fermarlo. Quanto più il sistema è autonomo e veloce, tanto più la supervisione effettiva diventa difficile — e tanto più il divario tra le due forme diventa la vera misura del rischio.

Per i sistemi con capacità riconvertibili questo si traduce in una domanda di governance molto operativa. Chi può ampliare il perimetro d’uso del sistema? Esiste una separazione tra chi lo amministra tecnicamente e chi ne autorizza nuove finalità? Le credenziali che consentono di estenderne le capacità sono tracciate, limitate, revocabili? In assenza di queste risposte, la supervisione umana è un’etichetta. E un sistema dual-use con una supervisione solo nominale è un sistema che può cambiare finalità senza che nessuno se ne accorga in tempo.

4. L’intersezione con NIS2: la capacità come superficie di attacco

C’è un secondo livello che la lettura puramente “privacy” del problema lascia in ombra. Un sistema di IA con capacità offensive riconvertibili non è solo un rischio per gli interessati: è un asset critico nell’architettura di sicurezza dell’organizzazione. E come ogni asset critico, ricade nel perimetro di NIS2 per i soggetti essenziali e importanti.

La Direttiva (UE) 2022/2555 impone una governance della sicurezza fondata sulla gestione continua del rischio, sul presidio della supply chain e sulla responsabilità diretta degli organi di vertice. Un sistema dotato di capacità tecniche elevate — accesso a infrastrutture, integrazione con sistemi legacy, credenziali ampie — è al tempo stesso uno strumento e una potenziale superficie di attacco. Se quelle capacità possono essere riconvertite, il rischio non è solo che l’organizzazione le usi male: è che un attaccante, ottenendone il controllo, le usi contro l’organizzazione stessa.

Questo collega il dual-use a un tema già noto e sistematicamente sottovalutato: la gestione degli accessi nel ciclo di vita del sistema. Un sistema potente le cui credenziali non vengono limitate, monitorate e — al momento della dismissione — revocate, lascia aperta una capacità riconvertibile fuori da ogni presidio. La fase finale del ciclo di vita, qui, non è un dettaglio amministrativo: è il momento in cui una capacità dual-use abbandonata diventa il rischio peggiore, perché nessuno la governa più e i suoi effetti tecnici persistono.

Una capacità offensiva riconvertibile e non presidiata non smette di esistere quando l’organizzazione smette di usarla. Resta. E chi non l’ha governata fino alla revoca degli accessi ne risponde comunque.

5. La convergenza dei tre regolamenti su un singolo oggetto

Il sistema di IA dual-use è il caso emblematico di ciò che già si osserva nel rapporto tra le tre normative europee: GDPR, AI Act e NIS2 non sono corpi paralleli, ma livelli che insistono sullo stesso oggetto. Un sistema con capacità riconvertibili che tratta dati personali, in un’organizzazione classificata come soggetto essenziale, attiva contemporaneamente tutti e tre i regimi.

Il GDPR chiede la base giuridica, la finalità determinata, la valutazione d’impatto sui diritti degli interessati. L’AI Act chiede la gestione del rischio specifico, la supervisione effettiva, la verifica di conformità da parte del deployer. NIS2 chiede il presidio della sicurezza, la gestione degli accessi, la responsabilità del management. Nessuno di questi livelli, da solo, intercetta il rischio dual-use nella sua interezza. Ed è precisamente nella terra di nessuno tra le tre funzioni — DPO, comitato IA, CISO — che la riconvertibilità offensiva trova lo spazio per restare non governata.

La frammentazione organizzativa, qui, non è un’inefficienza. È il rischio. Tre funzioni che parlano linguaggi diversi, rispondono a referenti diversi e leggono lo stesso sistema attraverso lenti diverse non producono governance: producono tre valutazioni che non si parlano su un oggetto che è uno solo.

6. Cosa può fare un’organizzazione, concretamente

Il punto non è rinunciare ai sistemi di IA avanzati perché dotati di capacità dual-use — sarebbe una posizione tanto irrealistica quanto sterile. Il punto è governare la riconvertibilità come una variabile esplicita del profilo di rischio, anziché scoprirla a posteriori. Alcune mosse sono alla portata di qualsiasi organizzazione strutturata.

Prima: mappare le capacità, non solo le finalità. Nella valutazione di un sistema di IA, accanto alla domanda “a cosa serve?” va posta la domanda “che altro può fare?”. La risposta — quando il fornitore è in grado di darla, e se non lo è questo è già un dato di governance — entra nel registro del rischio.

Seconda: presidiare il perimetro di autorizzazione. Definire chi può estendere l’uso del sistema oltre la finalità originaria, con quale processo e con quale tracciabilità. La riconversione non deve poter avvenire per inerzia tecnica.

Terza: rendere la supervisione umana effettiva e verificabile, non dichiarata. Misurare se chi supervisiona ha tempo, informazione e competenza — e documentare quella verifica, non solo l’esistenza del meccanismo.

Quarta: integrare le tre funzioni su questo oggetto. Un sistema dual-use richiede una valutazione condotta congiuntamente da chi presidia i dati, il rischio IA e la sicurezza. Non tre documenti paralleli: un’unica lettura coordinata, con responsabilità esplicite.

Quinta: governare la dismissione. Quando il sistema esce dall’operatività, revocare gli accessi, neutralizzare le capacità residue, documentare la decisione. Una capacità dual-use dimenticata è un rischio che sopravvive all’organizzazione che l’aveva introdotta.

Conclusione

Il segnale che arriva dalla frontiera dell’IA in cybersecurity non riguarda un’azienda o un’agenzia. Riguarda una soglia: i sistemi di IA hanno raggiunto un livello di capacità in cui la stessa tecnologia serve a difendere e ad attaccare, e la differenza la fa il governo dell’uso. Per chi guida un’organizzazione, questo trasforma il dual-use da categoria del diritto dell’export a categoria della governance ordinaria del rischio.

La domanda che ogni deployer dovrebbe porsi non è “il nostro sistema di IA è sicuro?”. È una domanda più scomoda: sappiamo cosa può fare oltre ciò per cui lo usiamo, chi potrebbe indirizzarlo altrove, e cosa lo impedisce oggi? Le organizzazioni che sapranno rispondere non saranno quelle con la tecnologia migliore. Saranno quelle che avranno costruito, prima dell’incidente e prima della prescrizione normativa, la capacità di governare ciò che la tecnologia rende possibile.

Un sistema di IA non è pericoloso o sicuro in sé. Lo diventa nel modo in cui viene governato — in ogni direzione che le sue capacità consentono. Riconoscere quelle direzioni, prima che lo faccia qualcun altro, è il lavoro della governance.

Ivano Pecis

DPO/RPD — Advisor in Governance, Privacy & Compliance

I&P Partners — Milano   |   ivano.pecis@partnerprivacy.it

Pubblicato sul blog I&P Partners. Le opinioni espresse sono dell’autore. Riproduzione consentita con citazione della fonte.