Tecnologia
Modelli AI open source e abuso criminale: come cambia la cybersecurity nel 2026
Rischi reali e contromisure pratiche: come i modelli AI open source e open weight abbassano il costo dell’attacco e costringono difesa e governance a cambiare passo. Focus su phishing, frodi con deepfake, LLM locali e sicurezza delle applicazioni con agenti. Aggiornato al 31/01/2026.
Pubblicato il: Sabato 31 gennaio 2026 alle ore 16:41.
Ultimo aggiornamento: Sabato 31 gennaio 2026 alle ore 17:44.
Per questo approfondimento abbiamo incrociato report di threat intelligence, pubblicazioni di enti pubblici e linee guida tecniche riconosciute. Quando riportiamo numeri o date, lo facciamo per dare contesto operativo. Se cerchi istruzioni per attaccare, qui non le trovi: l’obiettivo è capire i meccanismi e costruire difese più solide.
Se ti stai chiedendo quanto sia “nuovo” questo rischio, la risposta è più semplice di quanto sembri. Non serve un modello magico per fare danni. Basta un modello abbastanza capace da scrivere testi credibili, sintetizzare informazioni e aiutare a iterare velocemente. I modelli open source e open weight portano questa capacità offline e la mettono nelle mani di chiunque, inclusi gruppi criminali. Nel frattempo molte aziende stanno sperimentando LLM locali per privacy e costi, ma spesso li trattano come una demo e non come un servizio esposto. È qui che la cybersecurity cambia: meno fiducia nel “contenuto” e più controllo su identità, processi e supply chain.
Mappa rapida: cosa sta succedendo in quattro passaggi
| Passaggio | Cosa accade | Il segnale da notare | Conseguenza |
|---|---|---|---|
| La barriera si abbassa | Modelli AI open weight e open source diventano facili da scaricare e far girare localmente, spesso anche su hardware consumer. | L’attaccante non dipende da filtri o rate limit di un provider: può iterare offline e in silenzio. | La produzione di contenuti e script di ingegneria sociale scala senza attrito. |
| Dalla singola email alla catena automatizzata | L’AI viene collegata a OSINT, template e tool: il phishing diventa dialogo, non solo testo. | Messaggi coerenti con il contesto della vittima, tono naturale e meno “spigoli” linguistici. | Le difese basate solo sul contenuto perdono affidabilità e serve alzare il livello su identità e processo. |
| Il rischio speculare: LLM locali esposti | Sempre più aziende sperimentano LLM on premise per privacy e costi, ma li espongono in rete senza adeguate protezioni. | Endpoint di inferenza accessibili da Internet, log incompleti e chiavi lasciate in chiaro. | Crescono casi di abuso di risorse, fuga di dati e LLMjacking: il modello diventa un bersaglio. |
| Nuova cybersecurity: sicurezza per l’AI | Arrivano controlli specifici per LLM e agenti: prompt injection, tool calling, governance e supply chain dei modelli. | Adozione di framework e standard, più attenzione alla progettazione e al monitoraggio operativo. | La difesa si sposta su architettura, identità e resilienza, non su un singolo filtro miracoloso. |
Tip: la tabella è scorrevole. Su mobile scorri con il dito a destra e a sinistra per vedere tutte le colonne.
Un modello locale riduce la frizione per l’attaccante: niente filtri di piattaforma e iterazioni rapide.
La qualità linguistica non è più il punto: conta il contesto e la coerenza con i processi interni.
Molti endpoint di inferenza finiscono su Internet senza protezioni: è un rischio concreto e spesso invisibile.
Framework e standard per LLM e agenti aiutano a progettare controlli concreti, anche in ottica di compliance UE.
Quando un modello gira in locale e in silenzio, la difesa deve cambiare abitudini: meno fiducia nel testo “bello” e più controllo su identità, processi e dati.
Update log
Registro degli aggiornamenti sostanziali: trasparenza su modifiche, correzioni e integrazioni informative.
- Sabato 31 gennaio 2026 alle ore 17:07: Integrata la sezione su esposizione di LLM locali e sul rischio di LLMjacking con esempi recenti e contromisure concrete.
- Sabato 31 gennaio 2026 alle ore 17:23: Approfondita la parte “supply chain dei modelli” con focus su formati di serializzazione, deserializzazione e pratiche di hardening per chi scarica modelli da repository pubblici.
- Sabato 31 gennaio 2026 alle ore 17:44: Aggiornati playbook operativo e FAQ con riferimenti a framework e standard usati nel settore per sicurezza LLM e agenti.
Trasparenza: fonti e metodo
Questo approfondimento nasce da una lettura “da difensore”: cosa succede davvero quando i modelli diventano scaricabili, personalizzabili e integrabili in catene automatiche. Abbiamo privilegiato fonti primarie (enti pubblici, report ufficiali, framework tecnici) e le abbiamo incrociate con analisi di vendor di sicurezza quando aggiungevano dettagli operativi verificabili.
Per aiutarti a orientarti, trovi anche una parte più “terra terra”: controlli da mettere in produzione e punti ciechi tipici, soprattutto quando in azienda si sperimenta un LLM locale.
Fonti principali consultate: ENISA, Europol, Microsoft Security, NIST, OWASP, CISA, FBI, Interpol, Palo Alto Unit 42, SentinelOne, Trend Micro, Hugging Face.
Approfondimenti correlati
Tecnologia: news, guide e approfondimenti
Il nostro hub Tecnologia: trovi analisi, guide pratiche e aggiornamenti su AI, cybersecurity e innovazione digitale.
Apri la pagina hubContesto essenziale: perché i modelli open source spostano l’equilibrio
La discussione pubblica si incastra spesso su una domanda: “quanto è potente il modello?”. In sicurezza la domanda utile è un’altra: quanto costa provare. I modelli scaricabili abbassano il costo di iterazione, riducono la dipendenza da un fornitore e permettono di lavorare offline. In pratica, rendono più facile fare cento tentativi buoni invece di uno solo perfetto.
In parallelo, la cybersecurity sta già vivendo una trasformazione: i report più solidi continuano a mostrare che l’ingegneria sociale resta il vettore di accesso dominante. Se il phishing rimane una porta, l’AI rende quella porta più “ben arredata”: meno errori di lingua, più coerenza con il ruolo, più continuità nella conversazione. Per questo le difese stanno spostando l’attenzione su autenticazione, processi di verifica e controllo degli accessi, non solo su filtri anti spam.
In breve
- Modelli open source e open weight rendono più semplice attaccare in modo offline, iterativo e personalizzato.
- Phishing e frodi diventano più credibili: la differenza la fa il contesto, non la grammatica.
- Le aziende si espongono anche da sole quando mettono online endpoint LLM locali senza hardening.
- La sicurezza per LLM e agenti introduce rischi specifici: prompt injection, tool calling e supply chain dei modelli.
- Framework e norme aiutano a costruire una mappa: vanno tradotti in controlli pratici, non in burocrazia.
Il cambio di scenario: abuso criminale dei modelli AI open source
Ti propongo una lente semplice: immagina l’AI come un “motore” che trasforma tempo in tentativi. Per anni la qualità dell’attacco era limitata da lingua, conoscenza del dominio e pazienza. Ora il limite è sempre più spesso l’accesso al contesto e alle credenziali, non la capacità di scrivere un testo convincente.
Nota: quando descrivo tecniche di abuso, resto su un livello utile alla difesa e non entro in istruzioni operative.
Sommario dei contenuti
- Perché i modelli scaricabili cambiano le regole
- I pattern criminali che stanno già funzionando
- Il rischio sottovalutato: LLM locali esposti
- Il dettaglio trascurato: supply chain dei modelli
- Come cambia la cybersecurity nella pratica
- Playbook operativo: cosa fare adesso
- Norme e standard: cosa conta nel 2026
- FAQ
Perché i modelli scaricabili cambiano le regole
Molti servizi AI in cloud hanno controlli a monte: filtri sui contenuti, rate limit, sistemi di rilevamento di abuso e a volte tracciamento. Un modello scaricabile cambia il set di vincoli. Puoi eseguirlo in locale, dietro una VPN o in un’infrastruttura che non ha nessun motivo di “collaborare” con la difesa.
È anche qui che nasce un malinteso: “open source” non vuol dire automaticamente “senza rischi”. Anzi, spesso vuol dire “più responsabilità”. Se scegli un modello open weight per tenere i dati in casa, devi portare in casa anche i controlli che il provider ti dava gratis: autenticazione, logging, patching, segmentazione.
I pattern criminali che stanno già funzionando
Quando parliamo di abuso criminale, non stiamo parlando solo di email scritte meglio. Parliamo di un insieme di micro-automazioni che, messe in fila, riducono il costo del tentativo e aumentano la credibilità.
1) Spear phishing e BEC più coerenti
I report più recenti continuano a mettere il phishing al centro della scena. La parte nuova è il “come”. Un modello può prendere frammenti pubblici (ruoli, progetti, tono di comunicazione) e generare messaggi che sembrano uscire da una casella reale, soprattutto quando l’azienda ha processi fragili.
C’è anche un dato che vale la pena tenere a mente: studi sperimentali su soggetti umani hanno mostrato che, in certi contesti, le email generate con LLM possono raggiungere tassi di click molto più alti rispetto a email scritte manualmente. Non vuol dire che ogni attacco “AI” funziona. Vuol dire che il rischio medio cresce e che affidarsi alla sola “sensazione” dell’utente è sempre meno realistico.
2) Deepfake e impersonation: frodi che colpiscono i processi
Il deepfake è diventato un problema di cybersecurity perché colpisce la fiducia nei canali. La voce del “CEO” o il video del “collega” non sono prove. Sono input. Se la tua azienda autorizza bonifici o cambi IBAN senza una verifica robusta, l’AI non fa altro che rendere più credibile l’inganno.
Qui la difesa non è una tecnologia singola. È un protocollo: procedure di callback, conferme su canali indipendenti e regole chiare su cosa non si approva mai “al volo”.
3) Codice e malware: accelerazione del ciclo, non genialità improvvisa
I modelli open source possono aiutare a scrivere porzioni di codice, spiegare librerie, trasformare un’idea in un prototipo. L’uso criminale più comune non è “scrivere un ransomware da zero” in dieci secondi. È accelerare attività ripetitive: varianti, adattamenti, refactoring, offuscamenti banali, tentativi su tentativi.
Questo cambia la metrica con cui misuriamo la minaccia. Se prima un attacco “buono” era raro perché costoso, ora il rumore diventa più intelligente.
4) LLMjacking e abuso di endpoint
Una tendenza che sta emergendo con forza è l’abuso di risorse LLM altrui: endpoint lasciati aperti, gateway interni senza controllo o credenziali sottratte. Dal punto di vista del criminale, è un vantaggio doppio. Consuma compute che non paga e usa un’infrastruttura che sembra “legittima”.
5) “Phishing che si ricompone” in tempo reale
Alcune ricerche recenti hanno mostrato pagine di phishing che usano chiamate a servizi LLM per generare componenti malevoli o varianti di codice sul momento. È un trucco semplice ma efficace: rendere più difficile la firma statica e aumentare la variabilità. Se ti suona come un vecchio problema (polimorfismo) è perché lo è, solo traslato sul web moderno e sulla generazione.
Il rischio sottovalutato: LLM locali esposti
Se lavori in IT lo hai visto succedere con altre tecnologie: si parte con un POC, poi “tanto lo mettiamo un attimo online” e quella cosa diventa un servizio. Con i runner di modelli locali (Ollama e simili) sta succedendo lo stesso.
Nel gennaio 2026 sono state riportate analisi su un numero molto alto di istanze esposte pubblicamente. Il problema non è la curiosità di sperimentare. Il problema è che un endpoint di inferenza, se non protetto, può diventare un punto di fuga dati o un bersaglio di abuso.
Esempio pratico, verosimile: un team collega un LLM locale a documenti interni per “fare ricerca veloce”. Se l’endpoint finisce esposto o se un’app interna lo interroga senza controlli, un prompt injection ben piazzato può far recuperare informazioni che nessuno voleva rendere disponibili.
Il dettaglio trascurato: supply chain dei modelli
Qui entriamo in un punto che molti competitor citano in modo superficiale, spesso con una riga. In pratica però è una delle aree più delicate: un modello non è solo “pesi”. È un pacchetto di artefatti che interagiscono con runtime, librerie e, in alcuni casi, con codice esterno.
Nel mondo Python e ML, la deserializzazione insicura è un tema noto. Alcuni formati e workflow possono eseguire codice al momento del caricamento se il file è malevolo. Questo significa una cosa concreta: scaricare un modello da un repository pubblico e caricarlo “così com’è” può essere un rischio di supply chain.
La difesa qui è noiosa, ma funziona: preferire formati più sicuri (come safetensors quando disponibili), evitare l’esecuzione di codice remoto, isolare l’ambiente di inferenza e trattare modelli e dipendenze come componenti da validare. Se ti sembra “DevSecOps”, è esattamente quello.
Come cambia la cybersecurity nella pratica
La cybersecurity sta cambiando su due piani che si parlano poco. Il primo è classico: identità, accesso iniziale, frodi. Il secondo è nuovo: sicurezza dell’applicazione che include un LLM o un agente.
Sul primo piano, il messaggio è chiaro: quando il testo diventa indistinguibile, le difese devono spostarsi su segnali più robusti. DMARC, MFA resistente al phishing, controllo dei dispositivi, procedure di verifica pagamenti e segmentazione della rete restano fondamentali.
Sul secondo piano, entrano rischi specifici: prompt injection, output insicuro, eccesso di agency, tool design debole, poisoning dei dati. Se un agente può “fare cose” nel tuo ambiente, ogni integrazione deve essere progettata come una superficie di attacco.
Playbook operativo: cosa fare adesso
Se vuoi una linea pratica, eccola. Prima di pensare al modello “più bravo”, metti in sicurezza il contesto in cui quel modello vive. È lì che si vince o si perde.
Controlli minimi, ma seri, per LLM locali
- Non esporre endpoint di inferenza su Internet senza autenticazione forte e controllo di rete.
- Isola l’ambiente: container, permessi minimi, niente accesso diretto a share e database.
- Logga accessi e utilizzo con retention e alert su anomalie (picchi, prompt sospetti, tool invocati).
- Definisci chi può caricare modelli e con quali controlli di supply chain.
Controlli essenziali per app con agenti e tool calling
- Minimo privilegio per ogni tool e separazione dei ruoli: un agente non deve avere permessi “da admin” per comodità.
- Validazione dell’output prima dell’azione: se l’LLM genera un comando o una richiesta, serve un gate.
- Difesa contro prompt injection: controlli su input, su documenti recuperati in RAG e su istruzioni di sistema.
Norme e standard: cosa conta nel 2026
Nel 2026 il tema non è più “se regolamentare”, ma “come tradurre regole e standard in pratiche quotidiane”. In UE l’AI Act è entrato in vigore e alcune parti sono entrate in applicazione per step. In parallelo, i riferimenti tecnici si sono consolidati: framework come OWASP per i rischi LLM e linee guida NIST per la gestione del rischio GenAI vengono usati come mappa, anche quando non sono obbligatori.
Il punto non è fare compliance per paura. Il punto è usare quei riferimenti per evitare gli errori più comuni: sistemi troppo autonomi, dati esposti, assenza di logging e supply chain ignorata.
Guida pratica: cosa fare in azienda senza aspettare il prossimo incidente
Se gestisci un’azienda e temi frodi e phishing
Parti dai processi che muovono soldi e dati. Un attacco AI spesso non “buca” un firewall, buca una procedura. Metti una regola semplice e applicabile: per cambi IBAN, richieste urgenti e ordini fuori standard serve una conferma su un canale indipendente. Non perché il deepfake sia imbattibile, ma perché il costo dell’inganno diventa alto.
Se sei in IT o in un team di sicurezza
Tratta i modelli come componenti software. Se in azienda qualcuno sta facendo girare un LLM locale, chiedi subito dove gira, chi lo usa e se ha autenticazione. Se l’LLM è collegato a documenti o strumenti, fai threat modeling: cosa succede se un input malevolo entra nel contesto.
Promemoria pratico: un endpoint LLM esposto senza controlli non è una curiosità tecnica. È una superficie di attacco e va gestita come qualunque API critica.
Il commento dell’esperto
C’è un equivoco che vedo spesso quando si parla di AI e cybercrime: si discute solo di “capacità”. La leva vera, nel mondo reale, è il costo del tentativo. Se prima un attaccante doveva investire tempo per scrivere e rifinire, ora può farlo in parallelo e con meno fatica. Questo porta più attacchi plausibili, non necessariamente più sofisticati.
È anche il motivo per cui le difese devono spostarsi. Se l’email è scritta bene, il filtro linguistico perde potere. Restano solidi i controlli che non dipendono dallo stile: identità, autorizzazioni, processi di verifica e logging serio. La parte nuova è la sicurezza delle applicazioni con LLM: prompt injection, tool invocation e supply chain non sono parole alla moda, sono superfici concrete.
La correlazione che mi convince di più, guardando i report 2025 e 2026, è questa: quando l’AI entra nei flussi operativi, il confine tra “content” e “action” si assottiglia. E quando content e action si toccano, la sicurezza deve tornare a essere progettazione, non solo rilevamento.
Questo è un commento editoriale basato su evidenze pubbliche e linee guida tecniche. Le scelte di sicurezza vanno sempre contestualizzate alla tua organizzazione.
A cura di Junior Cristarella.
Domande frequenti
Quando dici “open source”, intendi davvero open source?
Nel linguaggio comune si usa “open source” per indicare modelli con pesi scaricabili. Tecnicamente molti sono “open weight” o “source available” con licenze specifiche. Per la sicurezza cambia poco per un criminale, ma cambia molto per un’azienda che deve rispettare licenze, audit e governance.
Un LLM locale è più sicuro di un servizio cloud?
Dipende. Un LLM locale può ridurre l’esposizione dei dati verso terzi, ma ti sposta addosso il lavoro di hardening, patching, autenticazione e monitoraggio. Il rischio tipico è l’endpoint lasciato esposto o troppo permissivo.
Che cos’è l’LLMjacking e perché sta emergendo?
È l’abuso di un endpoint o di credenziali legate a servizi LLM per consumare risorse, generare contenuti fraudolenti o tentare esfiltrazioni. Con la diffusione di LLM locali e gateway interni, cresce anche la superficie da “dirottare”.
Il phishing generato da AI è davvero più efficace?
Gli studi recenti e le osservazioni dei report di settore indicano che, in media, l’AI aumenta qualità e coerenza del testo e può far salire i tassi di interazione, soprattutto quando l’attacco è personalizzato. La differenza la fa il contesto: più informazioni ha l’attaccante, più il messaggio “suona giusto”.
Qual è il rischio più serio per chi integra un LLM con strumenti interni?
Prompt injection e invocazione malevola dei tool. Se un modello può agire (aprire ticket, leggere documenti, inviare email, spostare dati) allora l’attaccante non deve “bucare” il modello: gli basta manipolare il contesto per farlo agire male.
Come si riduce il rischio di scaricare un modello malevolo da un repository pubblico?
Tratta il modello come un pacchetto software: verifica provenienza, firma o checksum quando disponibili, preferisci formati più sicuri come safetensors, evita esecuzione di codice remoto e usa sandbox o container senza privilegi per test e inferenza.
Cosa devo chiedere a un fornitore che propone “AI per il SOC”?
Chiedi come gestisce log e retention, dove finiscono i dati, come mitiga prompt injection, come controlla le azioni automatiche degli agenti, quali audit fa sulla supply chain e con che ritmo aggiorna modelli e dipendenze.
L’AI Act cambia qualcosa per chi usa modelli open weight in azienda?
Sì, soprattutto sul tema governance, trasparenza e responsabilità. In UE alcune disposizioni sono già entrate in applicazione a scaglioni e il tema “AI literacy” è diventato un obbligo organizzativo. Tradotto: formazione e processi non sono più facoltativi.
Timeline del rischio: dal modello scaricato all’incidente
Tocca una fase per aprire i passaggi chiave. È una timeline pratica per non perdere i punti di controllo quando un LLM entra in azienda.
-
Fase 1 Scelta del modello e della licenza: non è un dettaglio
- Capire se è davvero open source o solo open weight con clausole: cambia cosa puoi fare e cosa rischi.
- Verificare provenienza e manutenzione: i modelli invecchiano come il software e vanno governati.
Perché conta: La governance parte dalla scelta: se non sai cosa porti in casa, non sai cosa proteggere.
-
Fase 2 Download e supply chain: il modello è un artifact eseguibile
- Oltre ai pesi scarichi codice, tokenizer e dipendenze che finiscono in produzione.
- Formati basati su pickle possono eseguire codice se il file è malevolo: è un rischio noto nel mondo ML.
- Opzioni comode come trust_remote_code amplificano la superficie di attacco se usate fuori da una sandbox.
- La scansione deve includere file accessori e dipendenze, non solo il “modello principale”.
Perché conta: La supply chain è un punto cieco frequente: molti incidenti nascono da ciò che trattiamo come “solo dati”.
-
Fase 3 Messa in produzione: dal POC al servizio esposto
- Se esponi un LLM locale, metti autenticazione, rate limit e controllo di rete: come per qualunque API.
- Isola il runtime: niente accesso diretto a database e file share senza un layer di autorizzazione.
- Logga input, output e azioni dei tool con retention chiara, tenendo d’occhio i dati sensibili.
Perché conta: Il salto da demo a servizio cambia il rischio: l’AI diventa parte della superficie esposta.
-
Fase 4 Abuso e incident response: quando l’AI entra nella kill chain
- Gli attaccanti usano modelli open per generare testi e varianti, ma il guadagno vero è la velocità di iterazione.
- Se un endpoint è bucato, l’impatto non è solo “costo token”: può diventare fuga di dati o abuso di tool collegati.
Perché conta: Un servizio AI non governato può trasformare un incidente tradizionale in un incidente più rapido e più difficile da contenere.
-
Fase 5 Nuove difese: identità, processi e sicurezza per agenti
- Rafforza l’identità: MFA resistente al phishing, DMARC e procedure di verifica pagamenti riducono i danni anche con messaggi perfetti.
- Per applicazioni con agenti, applica il minimo privilegio: ogni tool con permessi mirati e revocabili.
- Implementa guardrail tecnici: allowlist di azioni, validazione dell’output e controlli sui contenuti recuperati in RAG.
- Allena persone e processi contro deepfake e impersonation: la tecnica serve, ma contano anche le abitudini operative.
Perché conta: La difesa efficace alza la barriera dove l’attaccante deve comunque esporsi: identità, transazioni e autorizzazioni.
Chiusura
I modelli AI open source e open weight non “inventano” il cybercrime, ma cambiano la velocità e la scala con cui certe tecniche diventano accessibili. La difesa che regge è quella che non dipende dal testo perfetto: identità forte, processi di verifica, autorizzazioni minime e supply chain trattata come software. Se oggi stai adottando LLM e agenti, la domanda utile non è quale modello scegliere, ma quale superficie stai aggiungendo e con quali controlli.
