Dispensa - Intelligenza artificiale - Assistente informatico INPS

L'intelligenza artificiale (IA) rappresenta l'insieme di metodologie e tecnologie che consentono a un sistema informatico di eseguire compiti tipicamente associati all'intelligenza umana, quali riconoscimento di pattern, ragionamento, apprendimento e decisione. Il nucleo dell'IA moderna e' il machine learning (ML), ovvero la disciplina che studia algoritmi capaci di migliorare le proprie prestazioni mediante l'analisi di dati, senza che sia necessario programmare esplicitamente ogni regola.

Il processo di apprendimento si articola in tre fasi fondamentali: raccolta e preparazione dei dati, addestramento del modello e validazione. La qualita' dei dati influisce direttamente sulla capacita' predittiva: dati incompleti, rumorosi o distorti introducono bias che possono generare decisioni discriminatorie, soprattutto in ambito pubblico dove le decisioni hanno impatto su diritti dei cittadini. Per questo motivo la governance dei dati, il rispetto del GDPR (d.lgs. 196/2003) e la nomina di un Data Protection Officer (DPO) sono requisiti imprescindibili.

Nel contesto del machine learning, il modello e' una funzione parametrica che mappa un insieme di input (caratteristiche) a un output (predizione). I parametri, detti pesi, vengono ottimizzati mediante algoritmi di gradient descent, che minimizzano una loss function (funzione di perdita) misurando la differenza tra la predizione e il valore reale. Gli hyperparameter, invece, sono impostazioni che non vengono apprese durante l'addestramento (es. tasso di apprendimento, numero di strati) e richiedono una scelta preventiva, spesso mediante tecniche di ricerca a griglia o random.

Le tipologie di apprendimento piu' comuni sono:

Apprendimento supervisionato, dove al modello vengono forniti esempi etichettati; in questo caso si distinguono problemi di regressione (predizione di valori continui, es. stima del costo di un intervento) e di classificazione (assegnazione a categorie discrete, es. riconoscimento di una domanda ammissibile). Un errore tipico e' l'overfitting, cioe' quando il modello si adatta troppo ai dati di training, catturando rumore anziche' struttura, e quindi perde capacita' generalizzativa su dati nuovi.

Apprendimento non supervisionato si basa su dati privi di etichette e mira a scoprire strutture nascoste, come cluster o regole di associazione. Apprendimento per rinforzo prevede un agente che interagisce con un ambiente e apprende tramite ricompense o penalita'.

Il deep learning e' una sotto-classe del ML che utilizza reti neurali artificiali con molti strati (deep neural networks). Le convolutional layers sono particolarmente efficaci per l'elaborazione di immagini, poiche' estraggono automaticamente caratteristiche locali (bordo, texture) e le combinano in rappresentazioni piu' astratte, rendendo possibile il riconoscimento ottico dei documenti (OCR) o la classificazione di foto di infrastrutture pubbliche.

Un sistema esperto rappresenta una delle prime forme di IA: si tratta di un programma che codifica la conoscenza di un esperto umano in una base di regole (if‑then) e utilizza un motore di inferenza per risolvere problemi specifici, ad esempio la diagnosi di guasti in una rete elettrica.

Quando si combinano piu' modelli per migliorare le performance si parla di ensemble learning. Tecniche come bagging, boosting o stacking aggregano le predizioni di diversi classificatori, riducendo la varianza o il bias e aumentando la robustezza del sistema. Questo approccio e' particolarmente utile nella pubblica amministrazione, dove la precisione delle decisioni automatizzate deve essere garantita su dataset eterogenei.

Un aspetto critico per l'adozione dell'IA nella Pubblica Amministrazione e' la robustezza avversariale. Gli attaccanti possono introdurre piccole perturbazioni impercettibili agli input (ad es. modifiche minime a un'immagine di un documento) per ingannare il modello e farlo produrre risultati errati. La difesa richiede tecniche di addestramento avversario, validazione con dati perturbati e monitoraggio continuo delle predizioni.

Il Regolamento AI Act (proposta della Commissione Europea, 2021) introduce una classificazione a rischio dei sistemi IA. I sistemi ad alto rischio, come quelli impiegati per la valutazione di idoneita' a benefici sociali o per la gestione di procedure amministrative, devono rispettare requisiti stringenti di trasparenza, tracciabilita', gestione del rischio e supervisione umana. In pratica, prima del dispiegamento, l'amministrazione deve effettuare una valutazione d'impatto, documentare i dati di addestramento, garantire la spiegabilita' delle decisioni e prevedere meccanismi di ricorso per i cittadini.

La spiegabilita' si differenzia dall'interpretabilita'. L'interpretabilita' riguarda la comprensione intrinseca del funzionamento interno del modello (ad es. peso dei coefficienti in una regressione logistica), mentre la spiegabilita' fornisce giustificazioni post-hoc per una specifica predizione, spesso mediante tecniche come LIME o SHAP, utili per dimostrare la correttezza delle decisioni automatizzate.

Nel contesto della PA, l'uso dell'IA deve anche tenere conto del principio di minimo privilegio nella gestione degli accessi: solo gli operatori autorizzati devono poter modificare i parametri del modello o accedere ai dati sensibili. L'architettura cloud, sempre piu' diffusa, introduce concetti come la multitenancy, dove una singola istanza di servizio serve piu' enti (tenant) mantenendo isolamento logico dei dati, e la latenza di inferenza, che dipende dalla dimensione del modello, dalla potenza di calcolo disponibile e dalla distanza geografica tra client e server. Per applicazioni critiche (es. valutazione di richieste di assistenza), e' fondamentale dimensionare adeguatamente le risorse e prevedere meccanismi di caching o edge computing per ridurre i tempi di risposta.

Infine, la gestione del ciclo di vita di un progetto IA nella PA richiede una governance integrata: definizione di policy di sicurezza, monitoraggio continuo dei bias, audit periodici secondo le linee guida dell'AI Act, e coinvolgimento di stakeholder (cittadini, sindaci, responsabili di settore) per garantire trasparenza e legittimazione sociale. Solo con questo approccio sistemico l'IA potra' realizzare i benefici attesi, migliorando l'efficienza amministrativa senza compromettere i diritti fondamentali.

Nel contesto dell'intelligenza artificiale, i dati rappresentano il carburante indispensabile: senza un flusso continuo di informazioni corrette, aggiornate e pertinenti, anche l'algoritmo piu' sofisticato non puo' produrre risultati affidabili. Il ciclo di vita dei dati nella Pubblica Amministrazione parte dalla raccolta (ad esempio modulistica online, sensori IoT, archivio storico), passa per il trattamento (pulizia, normalizzazione, anonimizzazione) e termina con l'archiviazione o la cancellazione, in conformita' alle disposizioni di legge. Ogni fase deve essere documentata, poiche' la tracciabilita' e' un requisito fondamentale sia per il GDPR sia per l'AI Act, che richiedono la capacita' di ricostruire come un dato sia stato generato, trasformato e utilizzato da un modello di IA.

La qualita' dei dati non e' un concetto astratto: si articola in dimensioni misurabili quali accuratezza, completezza, coerenza, tempestivita' e pertinenza. Un dato inaccurato o incompleto puo' introdurre bias nel modello, generando decisioni discriminatorie o errate, con conseguenze legali e reputazionali per l'amministrazione. Per questo motivo, le amministrazioni devono adottare procedure di validazione automatica (controlli di formato, regole di business, confronti incrociati) e di revisione manuale, soprattutto per i dataset destinati a sistemi ad alto rischio. La documentazione di queste attivita', spesso sotto forma di data sheet o data card, costituisce un elemento di trasparenza richiesto dall'AI Act per le AI ad alto rischio.

La governance dei dati e' il quadro organizzativo che garantisce che le regole di qualita', sicurezza e privacy siano effettivamente applicate. In genere, la struttura prevede un Data Owner (responsabile della finalita' del dato e della sua disponibilita'), un Data Steward (custode della gestione operativa, della classificazione e del mantenimento del catalogo) e il Data Protection Officer (DPO), figura prevista dal Regolamento UE 2016/679 (GDPR). Il DPO ha il compito di vigilare sul rispetto dei principi di protezione dei dati personali, di fornire consulenza preventiva e di cooperare con l'Autorita' Garante per la protezione dei dati personali. Nel contesto dell'IA, il DPO partecipa attivamente alla redazione della Data Protection Impact Assessment (DPIA), valutando i rischi specifici legati al trattamento automatizzato e suggerendo misure di mitigazione, come la pseudonimizzazione o la limitazione dell'accesso ai dati sensibili.

Il GDPR enuncia otto principi fondamentali che devono guidare ogni operazione di trattamento: liceita', correttezza e trasparenza; limitazione della finalita'; minimizzazione dei dati; esattezza; limitazione della conservazione; integrita' e riservatezza; responsabilita'. Questi principi si traducono in obblighi concreti per i sistemi di IA nella PA: ad esempio, la minimizzazione richiede di utilizzare solo i dati strettamente necessari per l'addestramento, mentre l'esattezza impone meccanismi di aggiornamento periodico dei dataset per correggere eventuali errori. Il rispetto della trasparenza si concretizza nella produzione di documenti di spiegazione (model cards, datasheets) che descrivono le fonti dei dati, le tecniche di preprocessing e le limitazioni del modello.

L'AI Act, proposto dalla Commissione Europea e attualmente in fase di adozione, introduce una classificazione a quattro livelli di rischio per i sistemi di IA: inaccettabile, alto, limitato e minimo. Per le AI ad alto rischio, tipicamente quelle impiegate per decisioni amministrative automatizzate (es. valutazione di requisiti per benefici sociali, riconoscimento facciale per l'accesso a servizi), la normativa impone requisiti stringenti di governance dei dati. Tra questi, la necessita' di mantenere un registro dei dati di addestramento, di garantire la qualita' dei dati mediante controlli di bias e di fornire una funzionalita' di intervento umano (human-in-the-loop) per correggere decisioni errate. Inoltre, il fornitore del sistema deve predisporre una documentazione tecnica che includa la descrizione delle procedure di gestione dei dati, le metriche di performance e le misure di sicurezza adottate.

Un aspetto cruciale della governance e della privacy e' la gestione dei dati personali sensibili, come quelli relativi a salute, origine etnica o opinioni politiche. Il GDPR prevede categorie particolari di dati che richiedono un consenso esplicito o una base giuridica solida per il loro trattamento. Quando tali dati sono impiegati per addestrare un modello di IA, la normativa richiede l'adozione di tecniche di anonimizzazione o pseudonimizzazione, nonche' la limitazione dell'accesso ai soli soggetti autorizzati. Il DPO deve verificare che le misure tecniche e organizzative siano adeguate al livello di rischio, e deve monitorare eventuali violazioni attraverso il registro delle violazioni (art. 33 GDPR).

Infine, la governance dei dati nella PA deve integrarsi con le politiche di open data e di condivisione interistituzionale. La pubblicazione di dataset in forma aperta favorisce la trasparenza e l'innovazione, ma deve essere bilanciata con la tutela della privacy. Per questo motivo, le amministrazioni adottano linee guida che definiscono criteri di classificazione (pubblico, interno, riservato) e procedure di revisione preventiva prima della diffusione. In sintesi, la corretta gestione della qualita' dei dati, la strutturazione di un modello di governance solido e il rispetto delle disposizioni del GDPR e dell'AI Act costituiscono le fondamenta su cui si basa l'adozione responsabile dell'intelligenza artificiale nella Pubblica Amministrazione.

Nel contesto dell'intelligenza artificiale, il modello di apprendimento e' l'elemento centrale che consente di trasformare dati grezzi in previsioni o decisioni operative. I modelli si distinguono principalmente in base al tipo di variabile che si intende stimare e nella complessita' dell'architettura che li supporta. In questa sezione si approfondiscono quattro famiglie fondamentali: regressione, classificazione, ensemble e deep learning, con particolare riferimento all'applicazione nella pubblica amministrazione.

La regressione e' la tecnica utilizzata quando l'output da predire e' di natura continua. L'obiettivo consiste nel trovare una funzione f(x) che, a partire da un insieme di feature x, minimizzi la distanza rispetto al valore reale y. Il modello piu' semplice e' la regressione lineare, dove f(x)=w·x+b; tuttavia, per fenomeni non lineari si ricorre a regressioni polinomiali, a support vector regression o a metodi basati su alberi (ad esempio Random Forest Regressor). Nella pubblica amministrazione la regressione trova impiego nella previsione dei costi di gestione di un servizio, nella stima dei tempi di risposta di una pratica o nella modellazione della domanda di risorse sanitarie. La metrica tipica di valutazione e' il Mean Squared Error (MSE) o il Mean Absolute Error (MAE), che forniscono una misura immediata dell'errore medio commesso dal modello.

Quando l'output da produrre e' discreto, cioe' appartiene a una o piu' classi predefinite, si utilizza la classificazione. Algoritmi classici includono la regressione logistica, le macchine a vettori di supporto (SVM), gli alberi decisionali e i k-nearest neighbours. La scelta dell'algoritmo dipende dalla dimensionalita' dei dati, dalla presenza di correlazioni non lineari e dalla necessita' di interpretabilita'. Nella PA, la classificazione puo' supportare la verifica automatica dell'ammissibilita' di una domanda di contributo, la categorizzazione di segnalazioni di emergenza o la rilevazione di frodi in ambito fiscale. Le metriche di performance piu' utilizzate sono l'accuratezza, la precisione, il recall e l'F1-score; per problemi con classi sbilanciate, l'area sotto la curva ROC (AUC) fornisce un'indicazione piu' robusta.

Un singolo modello, per quanto ben calibrato, puo' presentare limiti legati a varianza elevata (overfitting) o a bias intrinseco (underfitting). L'ensemble learning affronta questi limiti combinando piu' modelli deboli in un modello forte. Le due strategie principali sono il bagging, che riduce la varianza mediante aggregazione di predizioni su sottoinsiemi di dati (es. Random Forest), e il boosting, che riduce il bias costruendo sequenzialmente modelli che correggono gli errori dei precedenti (es. AdaBoost, Gradient Boosting, XGBoost). Nella pratica amministrativa, gli ensemble sono particolarmente utili per scenari in cui la precisione e la robustezza sono requisiti normativi, ad esempio nella valutazione del rischio di credito per agevolazioni o nella classificazione di documenti legali. L'uso di ensemble, tuttavia, aumenta la complessita' computazionale e puo' ridurre la trasparenza, per cui occorre valutare attentamente il trade-off tra performance e spiegabilita'.

Il deep learning rappresenta l'estensione degli approcci di apprendimento verso reti neurali con molteplici strati (deep neural networks). Grazie alla capacita' di apprendere rappresentazioni gerarchiche, le reti profonde hanno rivoluzionato compiti di visione artificiale, elaborazione del linguaggio naturale e riconoscimento di pattern complessi. Architetture tipiche includono le Convolutional Neural Networks (CNN) per immagini, le Recurrent Neural Networks (RNN) e le loro varianti (LSTM, GRU) per sequenze temporali, e i Transformer per il linguaggio. Nella pubblica amministrazione, le CNN sono impiegate per l'OCR avanzato di documenti cartacei, le RNN per l'analisi di serie storiche di dati di traffico, e i Transformer per l'estrazione automatica di informazioni da testi normativi. Il processo di addestramento richiede grandi volumi di dati etichettati, potenza di calcolo (GPU/TPU) e una attenta gestione del fenomeno di overfitting, tipicamente mitigato con tecniche di regularizzazione (dropout, early stopping) e con la suddivisione dei dati in set di training, validation e test.

Un aspetto cruciale per l'adozione di modelli di deep learning nella PA e' la spiegabilita'. Poiche' le reti profonde sono per loro natura "black box", le autorita' devono garantire che le decisioni automatizzate siano comprensibili e verificabili. Tecniche di interpretazione post-hoc, come LIME (Local Interpretable Model-agnostic Explanations) o SHAP (SHapley Additive exPlanations), permettono di attribuire un peso a ciascuna feature per una singola predizione, fornendo una giustificazione che puo' essere inserita nei verbali di decisione. Inoltre, l'AI Act prevede che i sistemi ad alto rischio, compresi quelli destinati alla valutazione di diritti o all'allocazione di risorse pubbliche, debbano includere meccanismi di trasparenza e di ricorso umano.

In sintesi, la scelta tra regressione, classificazione, ensemble o deep learning dipende da tre fattori fondamentali: la natura dell'output richiesto, la complessita' del fenomeno da modellare e i vincoli di spiegabilita' e di risorse computazionali. Per progetti di piccola scala o con dati limitati, i modelli lineari o basati su alberi offrono un buon equilibrio tra performance e interpretabilita'. Per compiti piu' sofisticati, dove la precisione e la capacita' di gestire dati non strutturati sono decisive, gli ensemble avanzati e le reti profonde rappresentano la soluzione piu' efficace, purche' siano accompagnati da adeguate pratiche di validazione, monitoraggio continuo e documentazione conforme alle normative europee.

Le soluzioni di intelligenza artificiale offerte da fornitori cloud si basano su un modello di servizio che permette di accedere a risorse di calcolo, storage e reti senza dover gestire direttamente l'infrastruttura fisica. Questo modello, pur semplificando l'adozione di algoritmi complessi, introduce tre concetti tecnici fondamentali per la sicurezza, la scalabilita' e le performance: la multitenancy, la virtualizzazione e la latenza di inferenza.

La multitenancy indica la capacita' di una singola istanza di servizio (ad esempio un cluster di GPU o un servizio di model serving) di ospitare contemporaneamente piu' clienti, detti tenant, mantenendo per ognuno di essi un ambiente logico isolato. L'isolamento si ottiene mediante meccanismi di autorizzazione, reti virtuali separate e, soprattutto, tramite la segmentazione dei dati di addestramento e di inferenza. Per la pubblica amministrazione questo significa che un comune, un'agenzia regionale o un ente centrale possono condividere la stessa infrastruttura cloud senza che i dati sensibili di uno siano accessibili all'altro. Il rispetto del GDPR e dell'AI Act richiede che il titolare del trattamento dimostri la separazione dei dati personali e la tracciabilita' dei flussi di informazione, per cui la configurazione di tenant distinti e l'uso di policy di accesso basate su ruoli (RBAC) sono obbligatori.

La virtualizzazione e' la tecnologia che rende possibile la multitenancy. Essa si realizza attraverso hypervisor di tipo 1 (bare‑metal) o tipo 2 (hosted) che creano macchine virtuali (VM) o container isolati. Le VM offrono un livello di isolamento completo, compreso il kernel, ma introducono un overhead di avvio e di consumo di risorse. I container, invece, condividono lo stesso kernel dell'host e sono piu' leggeri, consentendo una scalabilita' rapida e un utilizzo ottimale delle GPU. In ambito AI, le piattaforme di orchestrazione (Kubernetes, OpenShift) gestiscono il ciclo di vita dei pod contenenti i modelli di inferenza, garantendo il bilanciamento del carico e la resilienza. La nested virtualization, ovvero la possibilita' di eseguire un hypervisor all'interno di una VM, permette di testare ambienti di sviluppo in modo identico a quello di produzione, ma deve essere usata con cautela perche' aumenta la latenza e la superficie di attacco.

La latenza di inferenza rappresenta il tempo trascorso dal momento in cui un client invia una richiesta di predizione al momento in cui riceve la risposta. Questa metrica e' critica per le applicazioni della PA che richiedono decisioni quasi in tempo reale, come il riconoscimento ottico dei documenti (OCR), il monitoraggio di flussi video per la sicurezza urbana o la valutazione automatica di domande di accesso a servizi sociali. La latenza dipende da quattro fattori principali:

• Dimensione e complessita' del modello: modelli deep piu' grandi (es. transformer con miliardi di parametri) richiedono piu' operazioni di matrice e quindi piu' tempo di calcolo.
• Potenza di calcolo disponibile: l'uso di GPU, TPU o acceleratori FPGA riduce drasticamente il tempo di esecuzione rispetto a CPU tradizionali.
• Complessita' dell'input: immagini ad alta risoluzione o sequenze audio lunghe richiedono pre‑processing piu' oneroso.
• Distanza geografica tra client e endpoint di inferenza: la propagazione del segnale attraverso la rete pubblica aggiunge ritardi, percio' le architetture multi‑region devono posizionare i nodi di serving vicino agli utenti finali, sfruttando le zone di disponibilita' offerte dai provider cloud.

Per minimizzare la latenza, le pubbliche amministrazioni possono adottare strategie quali il model quantization (riduzione della precisione dei pesi da 32 a 8 bit), il model pruning (rimozione di connessioni non significative) e il caching dei risultati per richieste ricorrenti. Inoltre, la scelta di un servizio di edge computing, dove l'inferenza avviene su dispositivi locali (es. gateway IoT) collegati a un backend cloud, consente di spostare il calcolo piu' vicino alla fonte dei dati, riducendo il round‑trip di rete.

Dal punto di vista della sicurezza, la multitenancy e la virtualizzazione introducono nuove superfici di attacco. Un attaccante che compromette una VM potrebbe tentare di eseguire attacchi di side‑channel per estrarre informazioni da un tenant concorrente, oppure sfruttare vulnerabilita' dell'hypervisor per ottenere privilegi di sistema. Per mitigare questi rischi, le linee guida dell'AI Act richiedono l'adozione di misure di hardening dell'hypervisor, l'uso di micro‑segmentazione di rete e la cifratura end‑to‑end dei dati in transito e a riposo. Inoltre, i log di accesso devono essere conservati per almeno tre anni, in conformita' al d.lgs. 196/2003 (Codice in materia di protezione dei dati personali) e al d.lgs. 82/2005 (Codice dell'amministrazione digitale), per consentire audit e tracciabilita' delle operazioni di training e inferenza.

Infine, la gestione operativa di un'architettura AI su cloud richiede un approccio DevOps/AI‑Ops: pipeline di CI/CD per il deployment dei modelli, monitoraggio continuo delle performance (tempo di risposta, utilizzo di GPU, tassi di errore) e meccanismi di rollback automatico in caso di regressioni. L'integrazione con sistemi di orchestrazione della sicurezza (SOAR) permette di automatizzare la risposta a incidenti legati a vulnerabilita' dei container o a anomalie di traffico verso gli endpoint di inferenza, garantendo la continuita' operativa anche in presenza di attacchi sofisticati.

I sistemi di intelligenza artificiale, soprattutto quando sono integrati in servizi della Pubblica Amministrazione, rappresentano un nuovo perimetro di attacco. La loro complessita' deriva non solo dal software tradizionale, ma anche dal modello di apprendimento, dai dati di addestramento e dalla catena di fornitura dell'infrastruttura cloud. Per valutare la sicurezza occorre distinguere tra minaccia (evento potenzialmente dannoso) e vulnerabilita' (debolezza che la minaccia puo' sfruttare). Un asset, nel contesto di un piano di sicurezza, e' qualsiasi risorsa di valore: dataset, modelli, API di inferenza, hardware di calcolo, credenziali di accesso e persino la reputazione dell'ente.

Le minacce piu' rilevanti per i sistemi AI possono essere raggruppate in quattro macro-categorie. La prima riguarda gli attacchi diretti al modello: evasion (o attacchi di esempio avversariale), poisoning dei dati di addestramento, model stealing e backdoor. L'evasion consiste nel modificare l'input con piccole perturbazioni, spesso impercettibili all'occhio umano, in modo da indurre il modello a produrre una risposta errata. Questo e' il nucleo della robustezza avversariale e rappresenta una vulnerabilita' critica per sistemi di riconoscimento facciale, classificazione di documenti o valutazione automatica di richieste di servizio. Il poisoning, invece, avviene durante la fase di addestramento: l'aggressore inserisce dati malevoli o manipolati nel dataset, corrompendo il modello in modo permanente. Il model stealing sfrutta le API di inferenza per ricostruire una copia approssimativa del modello originale, violando la proprieta' intellettuale e permettendo successivi attacchi di tipo evasion o inversione. Le backdoor (o trojan) consistono nell'inserire un comportamento nascosto attivabile solo da input specifici, rendendo il modello vulnerabile a manipolazioni future.

Una seconda categoria di minacce riguarda la catena di fornitura. I componenti software (framework di deep learning, librerie di ottimizzazione) possono contenere vulnerabilita' zero-day o codice malevolo inserito da fornitori terzi. L'uso di container o di immagini Docker non verificate espone il sistema a supply chain attacks. Inoltre, le piattaforme cloud multi-tenant introducono il rischio di side-channel attacks, dove un tenant malevolo puo' inferire informazioni sensibili dal modello di un altro tenant sfruttando la condivisione di risorse hardware.

La terza macro-categoria comprende le minacce operative. Qui rientrano gli attacchi di credential stuffing contro le interfacce di gestione dei modelli, il furto di chiavi API, e le intrusioni tramite vulnerabilita' note del sistema operativo o del database. Un attaccante che ottiene privilegi di amministratore puo' modificare i parametri di inferenza, disabilitare i meccanismi di logging o cancellare i log di audit, ostacolando la rilevazione. Anche le tecniche di Domain Generation Algorithm (DGA) possono essere usate per creare domini di comando e controllo (C2) che comunicano con botnet impiegati a lanciare attacchi DDoS contro i servizi di inferenza, compromettendo la disponibilita' del servizio.

Infine, le minacce legate ai dati includono il furto di dataset sensibili, l'esfiltrazione di informazioni tramite attacchi di membership inference (che consentono di capire se un dato specifico e' stato usato per addestrare il modello) e gli attacchi di model inversion (che ricostruiscono dati personali a partire dalle risposte del modello). Queste tecniche violano i principi di confidenzialita' e integrita' sanciti dal d.lgs. 196/2003 (Codice privacy) e dal GDPR, e sono particolarmente rilevanti per la PA, dove i dati trattati spesso includono informazioni sensibili dei cittadini.

Per difendere i sistemi AI e' necessario adottare un approccio defense-in-depth che integri le best practice della sicurezza tradizionale con contromisure specifiche per l'AI. Nella fase di progettazione, il risk assessment previsto dall'AI Act (art. 9) deve includere la valutazione di attacchi avversariali, di poisoning e di furto di modello. L'uso di ambienti di sviluppo isolati (sandbox) per il training, la firma digitale dei dataset e la verifica dell'integrita' mediante checksum riducono il rischio di contaminazione. Durante l'addestramento, tecniche di adversarial training e di data sanitization (rimozione di outlier sospetti) aumentano la robustezza del modello.

In produzione, la protezione delle API di inferenza deve basarsi su meccanismi di autenticazione forte (MFA, certificati client) e su rate limiting per prevenire il model stealing. Il monitoraggio continuo, tramite SIEM integrato con soluzioni SOAR, permette di correlare anomalie di traffico con possibili tentativi di evasion o di DGA. L'analisi dei log di inferenza, arricchita con Indicator Enrichment, consente di identificare pattern di abuso, come richieste ripetute con input quasi identici ma leggermente perturbati. In caso di rilevazione, il playbook SOAR puo' automatizzare la revoca delle credenziali compromesse, l'isolamento del servizio e l'attivazione di un piano di risposta gestito dal CSIRT interno o da un fornitore esterno.

La robustezza avversariale non si ottiene solo con tecniche di training, ma anche con test di penetration testing specifici per l'AI. Gli esperti di sicurezza devono eseguire adversarial red teaming, generando esempi avversariali reali e valutando la percentuale di successo del modello. I risultati guidano la scelta di contromisure come la randomizzazione dell'output, l'uso di detector networks per identificare input manipolati, o l'implementazione di certified defenses basate su verifiche formali. Inoltre, la documentazione della spiegabilita' del modello, richiesta dall'AI Act per sistemi ad alto rischio, aiuta a comprendere le decisioni errate e a individuare potenziali backdoor.

Infine, la continuita' operativa deve prevedere piani di backup e disaster recovery per i modelli e per i dataset di addestramento, nonche' procedure di live patching del kernel e di aggiornamento rapido delle librerie di deep learning, per mitigare le vulnerabilita' zero-day. La formazione periodica del personale, con focus su phishing mirato a rubare credenziali di amministrazione AI, completa il quadro di sicurezza, garantendo che l'intera catena di valore dell'intelligenza artificiale nella Pubblica Amministrazione sia protetta contro le minacce odierne e future.

Il quadro normativo che disciplina l'uso dell'intelligenza artificiale nella Pubblica Amministrazione nasce a due livelli: quello europeo, rappresentato dal Regolamento UE 2021/0100 (AI Act), e quello nazionale, che traduce e integra le disposizioni europee con specifiche disposizioni del Codice dell'Amministrazione Digitale (d.lgs. 82/2005 e successive modifiche) e con il Piano Nazionale per l'Intelligenza Artificiale (PNIA) approvato con d.lgs. 102/2022. L'AI Act, attualmente in fase di adozione definitiva, introduce una classificazione a quattro livelli di rischio (minimo, limitato, alto, inaccettabile) e stabilisce obblighi proporzionali al livello di rischio del sistema.

Per le amministrazioni pubbliche, la maggior parte dei sistemi AI rientra nella categoria alto rischio, poiche' sono impiegati per decisioni che incidono sui diritti fondamentali dei cittadini (ad esempio la valutazione automatica di domande di accesso a servizi sociali, il riconoscimento facciale per la sicurezza degli edifici pubblici o i sistemi di scoring per l'assegnazione di contributi). Un sistema ad alto rischio deve sottostare a una serie di requisiti obbligatori: gestione della qualità dei dati, trasparenza delle logiche di funzionamento, supervisione umana, robustezza contro attacchi avversariali e mantenimento di registri di conformità.

Il primo passo per una PA consiste nell'effettuare una valutazione d'impatto AI (AI Impact Assessment), analoga al DPIA previsto dal GDPR (Regolamento UE 2016/679). Tale valutazione deve identificare il livello di rischio, descrivere le misure di mitigazione, definire le responsabilità del Responsabile AI interno (spesso collocato presso l'ufficio per la trasformazione digitale) e prevedere un piano di monitoraggio post-implementazione. Il risultato della valutazione deve essere inserito nel Registro Nazionale dei Sistemi AI, gestito dal Ministero per la Pubblica Amministrazione in collaborazione con il Garante per la protezione dei dati personali.

Il rispetto dei requisiti di trasparenza prevede, per i sistemi ad alto rischio, l'obbligo di fornire all'utente finale una informativa chiara e comprensibile che indichi la presenza di un algoritmo, la sua finalità e le logiche decisionali di base (ad esempio mediante un "fact sheet" AI). Inoltre, deve essere garantita la possibilita' di intervento umano in caso di risultato errato o dubbio, e la registrazione di ogni intervento per fini di audit. La documentazione tecnica, comprensiva di architettura, dataset di addestramento, metriche di performance e test di robustezza avversariale, deve essere conservata per almeno cinque anni e resa disponibile alle autorità competenti su richiesta.

Le autorità di vigilanza sono due: a livello europeo il European Artificial Intelligence Board (EAIB), che emette linee guida e coordina le autorità nazionali; a livello italiano il Garante per la protezione dei dati personali, che verifica la coerenza con il GDPR, e il Ministero per la Pubblica Amministrazione, che controlla la conformità al CAD e al PNIA. In caso di sistemi classificati come "inaccettabile" (ad esempio tecnologie di sorveglianza biometrica in tempo reale senza adeguata base giuridica), l'AI Act prevede il divieto assoluto di utilizzo nella PA.

Il CAD, aggiornato con l'art. 71-bis del d.lgs. 82/2005, integra l'AI Act introducendo l'obbligo per le amministrazioni di predisporre un Piano di Sicurezza e Governance dell'AI. Tale piano deve includere: la definizione di policy di gestione dei dati (coerenza con il GDPR e con il principio del minimo privilegio), la designazione di un Data Protection Officer (DPO) con competenze specifiche sull'AI, la definizione di procedure di testing di robustezza avversariale e la predisposizione di un piano di continuità operativa che preveda backup dei modelli e dei dataset, nonché procedure di live migration per garantire la disponibilità dei servizi anche in caso di aggiornamento dei modelli.

Infine, la normativa prevede incentivi per l'adozione di soluzioni AI "responsabili". Le amministrazioni che dimostrano di aver implementato meccanismi di spiegabilità (ad esempio mediante tecniche di model-agnostic explanation come LIME o SHAP) e di aver ridotto al minimo i bias nei dataset possono accedere a finanziamenti dedicati dal Fondo per la Digitalizzazione della PA. Tale approccio incentiva la spiegabilita' non solo come requisito di conformità, ma anche come elemento di fiducia per i cittadini, contribuendo a consolidare la legittimita' dell'uso dell'AI nella gestione dei servizi pubblici.

Le amministrazioni pubbliche stanno adottando sistemi di intelligenza artificiale per automatizzare processi, migliorare l'efficienza e offrire servizi piu' rapidi ai cittadini. Tuttavia, l'uso di algoritmi in ambito decisionale richiede il rispetto di principi etici fondamentali sanciti dal d.lgs. 82/2005 (codice privacy), dal Regolamento UE 2016/679 (GDPR) e, piu' recentemente, dal AI Act (proposta 2021, in via di adozione). L'AI Act individua tra i requisiti obbligatori per le cosiddette "high-risk AI systems" la necessita' di garantire la dignita' umana, la non discriminazione, la responsabilita' e la trasparenza. In pratica, ogni algoritmo che influisce su diritti fondamentali o su scelte amministrative deve essere progettato e gestito in modo da poter essere controllato, spiegato e verificato da soggetti umani.

Il bias rappresenta una delle minacce etiche piu' insidiose. Esso si manifesta quando il risultato prodotto dal modello riflette in maniera distorta le disuguaglianze presenti nei dati di addestramento, nelle scelte di feature o nelle ipotesi di progettazione. Le fonti di bias possono essere di tipo storico (dati che riproducono discriminazioni passate), di campionamento (campioni non rappresentativi della popolazione) o di modello (scelte di algoritmo che privilegiano certe classi). Nel contesto della pubblica amministrazione, un algoritmo di valutazione delle domande di accesso ai servizi sociali che penalizza gruppi vulnerabili violerebbe l'art. 10 del AI Act (principio di equita') e l'art. 22 del GDPR (decisioni automatizzate che producono effetti giuridici). Per questo motivo, prima di procedere al dispiegamento, e' necessario effettuare una valutazione d'impatto specifica sul rischio di discriminazione, documentare le metriche di equita' e prevedere meccanismi di correzione.

Spiegabilita' e interpretabilita' sono due concetti spesso confusi ma distinti. L'interpretabilita' riguarda la capacita' intrinseca di comprendere come il modello elabora le informazioni: ad esempio, un albero decisionale e' intrinsecamente interpretabile perche' ogni nodo corrisponde a una regola leggibile. La spiegabilita', invece, si riferisce alla capacita' di fornire una giustificazione comprensibile per una decisione specifica, anche quando il modello sottostante e' opaco (come le reti neurali profonde). L'AI Act richiede, per i sistemi ad alto rischio, che le autorita' forniscano "explainability mechanisms" (art. 13) che consentano al cittadino di capire le ragioni di una decisione automatizzata e di contestarla, in linea con l'art. 15 del GDPR (diritto di accesso e di spiegazione). Tecniche come LIME, SHAP o i "counterfactual explanations" sono esempi di approcci post-hoc che permettono di generare spiegazioni locali senza dover rendere trasparente l'intera architettura del modello.

La trasparenza va oltre la sola spiegazione delle singole decisioni: implica la pubblicazione di una documentazione completa del ciclo di vita dell'algoritmo, nota come "registro algoritmico". Tale registro deve contenere la descrizione del caso d'uso, le fonti dei dati, le metriche di performance, le procedure di validazione, i risultati delle verifiche di bias e i piani di monitoraggio continuo. Il DPO, in collaborazione con il responsabile del trattamento, ha il compito di verificare che queste informazioni siano aggiornate e accessibili sia agli organi di controllo interno sia agli auditor esterni. Inoltre, la normativa richiede che le amministrazioni mantengano log di tutti gli input e output del sistema, in modo da garantire l'auditability e la tracciabilita' delle decisioni.

Per gestire i rischi etici, le pubbliche amministrazioni devono istituire un processo di governance strutturato. Questo prevede la costituzione di un comitato etico multidisciplinare, la realizzazione di una valutazione d'impatto sull'AI (AI Impact Assessment) prima del rilascio, e l'adozione di misure di mitigazione come il "debiasing" dei dati (rebalancing, reweighing) e la validazione incrociata su set di dati indipendenti. Il monitoraggio post-dispiegamento deve includere controlli periodici di equita' e di accuratezza, nonche' la possibilita' di intervenire manualmente in caso di risultati anomali. L'adozione di audit esterni, certificazioni di conformita' e la formazione continua del personale sono elementi chiave per garantire che gli algoritmi rimangano allineati ai valori democratici e alle disposizioni legislative.

Nei quiz, le domande tipiche riguardano la definizione di bias, le differenze tra spiegabilita' e interpretabilita', le obbligazioni di trasparenza previste dall'AI Act e le misure di mitigazione richieste dal GDPR. Per rispondere correttamente, occorre ricordare che il bias nasce da dati o modelli distorti, che la spiegabilita' fornisce una giustificazione post-hoc mentre l'interpretabilita' e' una caratteristica intrinseca del modello, e che la trasparenza richiede la pubblicazione di documentazione, log e meccanismi di audit. Collegare ogni concetto alla normativa specifica (art. 10 AI Act, art. 22 GDPR, art. 13 AI Act) permette di dimostrare una conoscenza approfondita e di superare le domande piu' insidiose della prova.

Nel contesto della Pubblica Amministrazione, l’adozione di sistemi di intelligenza artificiale non si limita alla fase di sviluppo del modello, ma richiede una progettazione operativa capace di garantire che l’AI sia integrata in modo sicuro, scalabile e conforme alle disposizioni del AI Act. L’integrazione parte dalla definizione di un'architettura a microservizi, dove ogni componente (preprocessing dei dati, inferenza, monitoraggio, logging) espone API RESTful o gRPC protette da meccanismi di autenticazione basati su IAM e su certificati TLS. L’uso di service mesh consente di gestire il traffico interno, applicare policy di sicurezza (mutual TLS, rate limiting) e raccogliere metriche di latenza di inferenza, fondamentali per rispettare i requisiti di disponibilità e di tempi di risposta previsti nei contratti di servizio della PA.

Per garantire la coerenza dei dati tra i sistemi legacy (ad es. anagrafiche, sistemi di gestione documentale) e le nuove piattaforme AI, si adottano pattern di integrazione basati su event streaming (Kafka, Azure Event Hub) e su bus di messaggi che permettono la propagazione asincrona degli eventi di business. I dati sensibili sono trattati in conformità al GDPR e al d.lgs. 82/2005, con classificazione, crittografia a riposo (AES-256) e a trasporto, e con l’attivazione di meccanismi di anonimizzazione o pseudonimizzazione prima dell’ingresso nei modelli di apprendimento.

Una volta che i componenti sono operativi, la orchestrazione delle attivita' di sicurezza e di risposta agli incidenti si realizza tramite piattaforme SOAR (Security Orchestration, Automation and Response). Il SOAR consente di definire playbook che collegano sistemi di SIEM, EDR, firewall, sistemi di gestione delle vulnerabilità e, nel caso specifico dell’AI, i moduli di monitoraggio dell’integrità dei modelli (drift detection, monitoraggio dei dati di input). Quando un indicatore di compromissione (IoC) viene generato, il SOAR arricchisce l’evento (Indicator Enrichment) aggiungendo informazioni su reputazione IP, geolocalizzazione e correlazioni con threat intelligence, per poi attivare azioni automatiche quali l’isolamento della VM compromessa, la revoca di token di accesso e l’avvio di una scansione di integrità sui file di modello.

La gestione degli incidenti segue il ciclo classico in cinque fasi, che il SOAR aiuta a coordinare in modo strutturato:

• Rilevazione: raccolta di log, alert e anomalie tramite SIEM e sistemi di anomaly-based detection.
• Analisi: correlazione automatica degli alert, arricchimento degli indicatori e assegnazione di priorità in base al impact sui servizi pubblici.
• Contenimento: esecuzione di script di isolamento, blocco di account compromessi (credential stuffing) e attivazione di policy di zero trust.
• Eradicazione e recupero: rimozione di malware, patching delle vulnerabilità e ripristino dei dati da backup verificati.
• Lezioni apprese: aggiornamento dei playbook, revisione delle configurazioni di sicurezza e comunicazione al CSIRT interno.

Nel contesto della PA, il CSIRT interno e' costituito da personale appartenente all’ente, con conoscenza approfondita dei processi amministrativi e delle normative di settore; il CSIRT esterno, invece, e' un fornitore specializzato che offre competenze tecniche avanzate, capacita' di threat hunting e risorse di risposta 24/7. La scelta tra le due tipologie dipende dal livello di criticità dei servizi AI, dalla disponibilità di risorse interne e dalla necessità di garantire continuità anche in caso di eventi di grande impatto.

La continuità operativa di un sistema AI nella PA si basa su tre pilastri: alta disponibilità, disaster recovery (DR) e gestione delle patch. L’alta disponibilità viene ottenuta mediante architetture ridondanti (cluster di inferenza, bilanciatori di carico) e tramite live migration delle macchine virtuali, che permette di spostare le VM in esecuzione da un host all’altro senza interruzione del servizio, riducendo al minimo il tempo di inattività. Il piano di DR prevede la replica geografica dei dati di addestramento e dei modelli, backup periodici su storage a prova di ransomware e test periodici di failover per verificare il rispetto degli SLA. Inoltre, il patch management deve includere il live patching del kernel per applicare correzioni di sicurezza critiche senza richiedere riavvii, limitando l’esposizione a vulnerabilità zero-day.

Un aspetto peculiare dell’AI nella PA riguarda la necessità di monitorare costantemente il model drift e la robustezza avversariale. Qualsiasi variazione dei dati di input, anche se piccola, può indurre errori di classificazione che, in ambito pubblico, si traducono in decisioni amministrative errate. Per questo motivo, i sistemi di monitoraggio devono includere controlli di integrità dei dati (checksum, firme digitali) e meccanismi di rilevamento di attacchi avversariali, con la possibilità di attivare automaticamente un rollback alla versione precedente del modello, garantendo che le operazioni di erogazione dei servizi non vengano interrotte.

Infine, la governance operativa deve prevedere la documentazione completa di tutti i processi di integrazione, orchestrazione e risposta, in modo da soddisfare gli obblighi di trasparenza richiesti dall’AI Act (art. 9) e dal d.lgs. 33/2013 in materia di pubblicazione dei dati di performance. La redazione di report periodici, la definizione di metriche di Mean Time To Detect (MTTD) e Mean Time To Respond (MTTR) e la verifica della conformità alle policy di least privilege completano il quadro di una progettazione operativa solida, capace di garantire che l’intelligenza artificiale sia un valore aggiunto per la Pubblica Amministrazione, senza compromettere la sicurezza, la privacy o la continuità dei servizi.

Nei quiz che verficano le competenze sull'intelligenza artificiale nella pubblica amministrazione, le domande tendono a combinare concetti tecnici con riferimenti normativi. Il primo ostacolo e' la presenza di termini quasi sinonimi ma con sfumature operative diverse: multitenancy, virtualizzazione, nested virtualization o live migration. Spesso il candidato si affida a una conoscenza superficiale e sceglie l'opzione che sembra piu' "tecnologica", dimenticando che la definizione precisa di multitenancy riguarda la condivisione di una singola istanza di software o infrastruttura tra piu' tenant isolati, non la semplice capacita' di spostare una VM. Per evitare l'errore, occorre fissare nella mente la frase chiave "una sola istanza, piu' clienti, isolamento logico".

Un'altra trappola ricorre quando la domanda inserisce un aggettivo qualificante (ad esempio "principalmente", "solo", "in ambito pubblico") e le risposte includono affermazioni piu' generiche. Nel contesto dell'AI Act, la distinzione tra "sistema ad alto rischio" e "sistema a rischio limitato" e' fondamentale: il primo richiede valutazioni di conformita' pre-mercato, il secondo no. Se la domanda chiede "qual e' l'obbligo principale per un sistema AI ad alto rischio nella PA", la risposta corretta deve includere la valutazione di conformita' e la documentazione del rischio, non semplicemente la "sicurezza dei dati". Leggere con attenzione il qualificatore evita di cadere nella risposta troppo ampia.

Le domande che mescolano concetti di sicurezza informatica con quelli di AI possono indurre a confondere termini come "robustezza avversariale" e "robustezza operativa". La prima si riferisce alla capacita' del modello di resistere a perturbazioni intenzionali dell'input (ad es. attacchi di tipo adversarial), mentre la seconda riguarda la disponibilita' del servizio in caso di carico o guasti. Quando una risposta menziona "garanzia di disponibilita' in caso di attacco DDoS", non e' la definizione corretta di robustezza avversariale. Il trucco sta nel associare la parola "avversariale" al concetto di "adversarial attack".

Un ulteriore inganno comune e' la presenza di risposte "tutte le precedenti" o "nessuna delle precedenti". Queste opzioni sono corrette solo se il candidato ha verificato l'esattezza di ciascuna affermazione precedente. Per esempio, nella domanda su "qual e' il ruolo del Data Protection Officer (DPO) rispetto al trattamento dei dati personali", le tre affermazioni proposte spesso includono una leggera imprecisione (ad es. "il DPO decide le finalita' del trattamento"). Se anche una sola affermazione e' imprecisa, l'opzione "tutte le precedenti" e' errata. La strategia migliore consiste nel valutare ogni frase singolarmente, piuttosto che affidarsi all'istinto.

Per quanto riguarda le domande che richiedono la distinzione tra interpretabilita' e spiegabilita', la trappola sta nel confondere il livello di astrazione. L'interpretabilita' riguarda la comprensione intrinseca del modello (ad es. un albero decisionale), mentre la spiegabilita' si riferisce a una giustificazione post-hoc per una decisione specifica (ad es. LIME o SHAP). Se una risposta dice "l'interpretabilita' fornisce una spiegazione per ogni predizione", e' sbagliata, poiche' la spiegabilita' e' quella che fornisce la giustificazione per una singola predizione.

Strategie operative per affrontare i quiz

• Leggi con attenzione il testo della domanda e individua le parole chiave: "solo", "principalmente", "in ambito pubblico", "ad alto rischio". Queste parole determinano il campo di validita' della risposta.
• Prima di guardare le opzioni, formula mentalmente la definizione corretta. Solo dopo, confrontala con le proposte per eliminare quelle che contengono termini fuori contesto o che aggiungono elementi non richiesti.
• Usa il metodo di eliminazione: scarta le risposte che includono concetti appartenenti a domini diversi (ad es. "overfitting" in una domanda sulla crittografia). Questo riduce il rischio di scegliere una risposta "troppo ampia".
• Quando la domanda richiama una norma (es. d.lgs. 82/2005, AI Act), ricorda il riferimento preciso (articolo, comma) e verifica se la risposta lo cita correttamente. Spesso le opzioni includono una citazione parziale o errata.
• Attenzione alle risposte "tutte le precedenti": verifica l'esattezza di ogni affermazione. Se una sola e' dubbia, scegli l'opzione che esclude quella specifica.

Infine, per le domande che combinano aspetti etici e tecnici, come il rischio di bias in un sistema AI per l'assegnazione di servizi sociali, la risposta corretta deve evidenziare il pericolo di decisioni discriminatorie verso categorie vulnerabili, non semplicemente la "qualita' dei dati". Ricordare che nella PA il principio di equita' e non discriminazione ha valore costituzionale aiuta a selezionare l'opzione piu' aderente al contesto normativo.