Nel dibattito pubblico sull’Intelligenza Artificiale, i Large Language Models vengono spesso presentati come strumenti che “scrivono bene”. Nella realtà della Pubblica Amministrazione, invece, stanno rapidamente diventando componenti di processo: aiutano a leggere e sintetizzare atti, a interrogare basi documentali tramite RAG, a redigere bozze, a classificare richieste e, in prospettiva, a compiere azioni in autonomia o semi-autonomia. È qui che la cybersecurity smette di essere una disciplina “a valle” e torna a essere ciò che dovrebbe: governo del rischio, architettura, controllo e cultura organizzativa.
In questo contesto, il CERT-AgID è un pezzo importante dell’ecosistema pubblico perché non si limita a produrre indicazioni generali. Lavora su strumenti, servizi e materiali che possono essere messi a terra anche in amministrazioni con capacità tecniche limitate, e in parallelo alimenta un filone di approfondimento sulla sicurezza dei sistemi basati su LLM che, per una PA, non è un lusso accademico: è preparazione operativa.
Indice degli argomenti
Cosa fa il CERT-AgID e perché serve anche quando parliamo di LLM
Il CERT-AgID, per come si colloca e per la natura dei servizi che rende disponibili, aiuta le amministrazioni a spostare l’attenzione dalla sola “gestione dell’emergenza” alla prevenzione: ridurre esposizione, aumentare capacità di rilevazione, standardizzare verifiche e diffondere cultura. È un approccio particolarmente rilevante ora, perché l’adozione di LLM e RAG tende a introdurre un nuovo strato applicativo che si appoggia comunque su fondamentali classici: identità, canali sicuri, aggiornamento dei sistemi, logging, gestione dei fornitori e controllo delle superfici esposte.
Il Feed degli Indicatori di Compromissione (IoC) è un esempio concreto di questa logica: trasformare l’intelligence in qualcosa di consumabile. L’idea è semplice ma efficace: condividere in modo tempestivo indicatori raccolti durante le attività di monitoraggio per prevenire e contrastare minacce come malware e phishing. In pratica, per una PA significa poter integrare segnali aggiornati nei propri sistemi di controllo e nel proprio “senso del pericolo”, senza dover costruire da zero una capability di threat intelligence.
Hashr, invece, porta sul tavolo un’operatività più “terra-terra”: computare hash dei file e confrontarli con liste predefinite (ad esempio IoC di hash). Sembra un tema da laboratorio, ma è uno di quei mattoni che fanno la differenza quando occorre verificare rapidamente se un ambiente contiene file sospetti o già noti. Anche qui, l’impatto sugli scenari LLM è indiretto ma reale: l’innovazione nella persuasione linguistica (phishing più credibile, contenuti più mirati) spesso conduce comunque a compromissioni tradizionali, e avere strumenti semplici e replicabili per i controlli resta vitale.
Le Misure minime di sicurezza ICT per le Pubbliche Amministrazioni sono rimaste per diversi anni il “nucleo duro” della disciplina: un riferimento pratico per valutare e migliorare il livello di sicurezza in modo strutturato. È il punto che molti saltano quando inseguono l’IA: prima di mettere un assistente generativo in un processo, bisogna essere certi di avere basi solide su accessi, backup, gestione delle vulnerabilità, segmentazione, tracciamento e policy. Altrimenti l’LLM non è un acceleratore: è un moltiplicatore di rischio.
Ricordiamo per dovere di cronaca che sono state superate da ACN con il decreto 344695 del 30 ottobre 2025.
Lo stesso vale per le raccomandazioni sul protocollo TLS e sulle Cipher Suite: non fanno notizia, ma sono infrastruttura. Se canali e integrazioni non sono protetti a regola d’arte, ogni componente applicativa — inclusi i servizi IA e le API che li collegano ai sistemi interni — eredita fragilità difficili da compensare con “prompt ben scritti”.
Infine, l’autoverifica della configurazione HTTPS e dello stato di aggiornamento del CMS per i siti della PA è un servizio che esprime bene la filosofia CERT-AgID: controlli standardizzati, accessibili, che aiutano a costruire baseline misurabili e ripetibili. E in parallelo, la dimensione formativa e culturale completa il quadro: la sicurezza non è solo tecnologia, è comportamento organizzativo. In un mondo in cui prompt injection e manipolazione linguistica diventano attacchi plausibili, una PA che non ha interiorizzato le regole base contro phishing e social engineering parte strutturalmente svantaggiata.
A tutto questo va aggiunta la formazione periodica che il CERT-AgID rende disponibile alle pubbliche amministrazioni.
CERT-AgID e ACN: ruoli diversi, stessa filiera di sicurezza
È utile leggere CERT-AgID e ACN non come entità sovrapposte, ma come funzioni distinte in una filiera unica. L’ACN presidia la cybersicurezza nazionale e ospita lo CSIRT Italia, che svolge compiti tipici di un CSIRT nazionale: coordinamento, gestione e supporto nella risposta agli incidenti, emissione di allerte e raccordo con gli obblighi di segnalazione.
Il CERT-AgID, invece, si colloca più sul versante abilitante e preventivo per l’ecosistema pubblico: strumenti, servizi e iniziative che aumentano il livello medio di sicurezza, rendendo più difficile l’attacco e più veloce l’individuazione delle anomalie. In termini molto concreti, se la sicurezza fosse una catena di montaggio, l’ACN lavora fortemente sul governo e sulla risposta coordinata quando l’incidente c’è (o quando serve un quadro nazionale), mentre il CERT-AgID lavora su ciò che riduce la probabilità e l’impatto dell’incidente prima che si manifesti, e su ciò che permette alle singole amministrazioni di maturare pratiche e controlli.
Questo punto è decisivo quando introduciamo LLM e RAG: la tentazione è pensare che la sicurezza sia “un tema del fornitore” o “un tema da incident response”. In realtà la partita si gioca prima: nelle scelte architetturali, nei permessi, nei log, nelle interfacce che colleghiamo al modello, nella qualità e governabilità delle basi documentali e nella disciplina operativa quotidiana. Ed è proprio qui che l’approccio del CERT-AgID tende a essere più immediatamente traducibile in azioni per la PA.
Tre paper del CERT-AgID su sicurezza e LLM: il valore sta nella comprensione, non nello slogan
Il paper sugli agenti IA sposta l’attenzione su una trasformazione che molte organizzazioni sottovalutano.
Agenti IA e sicurezza: comprendere per governare
Quando un LLM smette di essere solo un’interfaccia conversazionale e diventa un agente collegato a strumenti, file, sistemi operativi o API di servizi, il rischio cambia natura. Non stiamo più parlando soltanto di qualità della risposta, ma della possibilità che l’IA compia azioni, manipoli dati, produca effetti in ambienti reali.
Questo rende cruciale il collante tra modello e strumenti: wrapper, policy di esecuzione, scoping dei permessi, segregazione degli ambienti, auditabilità. In sostanza, l’agente diventa una nuova figura applicativa e va trattato come tale: progettato con guardrail, limitazioni, controlli e test.
Nella prospettiva PA, il messaggio è molto concreto: l’agentic AI è interessante perché promette produttività, ma al tempo stesso può diventare un acceleratore di errori, leak o escalation se non viene governata con logiche di sicurezza by design. E “by design”, qui, non è uno slogan: significa architettura, governance dei privilegi e verifiche prima del rilascio, non dopo l’incidente.
Tre punti salienti
- L’IA agentica sposta il rischio dalla “risposta testuale” all’“azione operativa” su sistemi e dati.
- La sicurezza dipende in larga parte dall’integrazione modello–strumenti (permessi, wrapper, policy, logging), non dal solo prompt.
- Serve threat modeling specifico per agenti: scoping dei privilegi, segregazione ambienti e test preventivi.
Analisi del rifiuto nei modelli linguistici
Il paper sul rifiuto affronta un tema che, nella discussione pubblica, viene spesso semplificato: “il modello rifiuta le richieste pericolose”. La realtà è più complessa, e comprenderla è utile anche per chi non fa ricerca. Qui l’attenzione è su come e dove nasce il comportamento di rifiuto, e sul fatto che non si tratti di un interruttore binario.
L’idea che emerge è che la risposta del modello sia il risultato di un processo stratificato: lungo i layer si formano segnali e decisioni, e questo processo può essere influenzato o deviato con tecniche mirate. Per una PA che sta valutando soluzioni LLM, il punto non è “imparare a bypassare le protezioni”, ma interiorizzare una lezione di governance: non basta fidarsi di policy dichiarate o di un generico “sistema sicuro”.
Se esistono modalità per far deragliare il comportamento del modello, allora servono valutazioni strutturate, red teaming, monitoraggio e presidi che non si limitino alla fase di configurazione iniziale.
Tre punti salienti
- Il rifiuto non è un interruttore: emerge come processo lungo gli strati del modello.
- Esistono tecniche che possono influenzare il percorso decisionale e indebolire le barriere.
- Implicazione di governance: non basta la policy del fornitore; servono test, red teaming e monitoraggio.
Bias decisionale indotto da istruzioni normative nei sistemi RAG
Il paper sul bias decisionale in RAG tocca un nervo scoperto della PA: il rapporto tra evidenza documentale e autorità delle istruzioni. Nei sistemi RAG, il modello riceve contenuti recuperati dinamicamente da basi documentali. Ma quei contenuti sono, per l’LLM, “testo” e basta: una descrizione fattuale e un’istruzione normativa possono essere trattate come elementi sullo stesso piano, con il rischio che l’IA privilegi la parte prescrittiva o l’“autorità apparente” dell’indicazione, anche quando confligge con i fatti.
Questo tema è particolarmente delicato nei processi amministrativi, perché le decisioni (o le pre-decisioni) sono spesso costruite su corpus documentali eterogenei: atti, note interne, manuali, FAQ, circolari, interpretazioni. Se in quel contesto entrano istruzioni manipolative o anche solo frasi “forti” posizionate strategicamente, l’LLM può essere spinto a una conclusione distorta senza che i dati sottostanti siano stati alterati.
È una forma di attacco e di rischio che assomiglia alla disinformazione, ma applicata alla catena decisionale. E per questo richiede mitigazioni che vanno oltre il prompt: curatela delle fonti, controlli di qualità del knowledge base, meccanismi di evidenza e contraddittorio, e una progettazione del sistema che non confonda “autorità” con “verità”.
Tre punti salienti
- Nei RAG fatti e istruzioni possono entrare in conflitto, ma per l’LLM sono entrambi “testo”.
- I modelli possono essere influenzati da istruzioni normative/autoritative anche contro l’evidenza documentale.
- Serve governance del knowledge base e del meccanismo di evidenza: curatela fonti, controlli qualità, mitigazioni oltre il prompt.
Conclusione: il valore del CERT-AgID sui LLM è pragmatico, e serve alla PA
C’è un aspetto che merita di essere detto con chiarezza: il lavoro del CERT-AgID sui LLM non è curiosità tecnologica. È un investimento pubblico su comprensione e governabilità, cioè sulle due cose che alla PA mancano più spesso quando deve adottare innovazioni che diventano subito infrastruttura.
Da un lato, il CERT-AgID continua a mettere a disposizione strumenti e servizi che agiscono sui fondamentali (IoC, verifiche HTTPS/CMS, raccomandazioni tecniche, misure minime, formazione). Dall’altro, apre una traiettoria di analisi su agenti, rifiuti e bias in RAG che intercetta precisamente i rischi che la PA incontrerà quando i modelli entreranno stabilmente nei processi: non solo “cosa risponde”, ma “cosa influenza”, “cosa fa”, “cosa può essere indotto a fare”.
Se l’LLM è destinato a diventare un nuovo livello applicativo della PA, il CERT-AgID sta facendo un lavoro essenziale: trasformare la sicurezza dell’IA da tema astratto a tema governabile, traducibile in scelte architetturali, controlli, verifiche e cultura. È esattamente ciò che serve per evitare che l’innovazione diventi, ancora una volta, un debito operativo che qualcuno dovrà pagare quando sarà troppo tardi.
