Mettere in sicurezza l'AI in azienda: cosa chiede davvero l'AI Act

L'adozione dell'AI in azienda è passata, in pochi mesi, da sperimentazione a infrastruttura. Assistenti che leggono la posta, agenti che interrogano i gestionali, copiloti che scrivono codice: tutti strumenti che oggi toccano dati reali e prendono, o suggeriscono, decisioni operative. Il problema è che molte integrazioni sono state fatte senza un modello di minaccia. E nel frattempo il quadro normativo è cambiato: per alcuni usi dell'AI la sicurezza è un obbligo specifico, per tutti è diventata un tema di governance.

Perché la sicurezza dell'AI è ora un obbligo

Il Regolamento (UE) 2024/1689, l'AI Act, è in vigore dal 1 agosto 2024 e si applica per fasi. Due articoli interessano direttamente chi adotta strumenti di AI, anche una PMI che non sviluppa nulla in proprio.

L'articolo 4 introduce l'obbligo di AI literacy. Fornitori e deployer devono garantire un livello adeguato di competenza sull'AI al personale e a chiunque, per loro conto, si occupi del funzionamento e dell'uso dei sistemi di AI. Questo obbligo si applica dal 2 febbraio 2025. Non richiede certificazioni: richiede che le persone che usano questi strumenti capiscano cosa stanno usando, quali sono i limiti e quali i rischi.

L'articolo 15 riguarda i sistemi di AI ad alto rischio. Stabilisce che devono essere progettati per raggiungere un livello adeguato di accuratezza, robustezza e cybersecurity, e per mantenerlo in modo coerente per tutto il ciclo di vita. Il testo è esplicito: i sistemi devono essere resilienti rispetto ai tentativi di terzi di alterarne l'uso, l'output o le prestazioni sfruttando vulnerabilità. Cita minacce specifiche dell'AI, fra cui data poisoning, model poisoning, model evasion e attacchi alla riservatezza del modello.

Anche se la tua azienda non opera sistemi classificati ad alto rischio, l'articolo 15 è un riferimento tecnico forte su cosa significhi "AI sicura". Trattarlo come baseline di progettazione è una scelta difendibile: non perché ogni sistema ricada automaticamente nell'articolo 15, ma perché accuratezza, robustezza, cybersecurity e tracciabilità sono requisiti sensati per qualunque AI che tocchi dati o processi aziendali.

Le minacce reali, senza allarmismo

Le minacce ai sistemi di AI non sono teoriche. Sono attive, documentate e spesso banali da eseguire.

Prompt injection. È la vulnerabilità numero uno. Un'istruzione malevola, nascosta in un contenuto che il modello legge, dirotta il comportamento dell'agente. Non serve un sito ostile: basta una pagina web indicizzata, una mail in arrivo, un PDF allegato, una riga in un ticket. Se il tuo assistente legge la casella di posta, chiunque può scrivergli.

Injection indiretta. È la variante che fa più danni. L'attaccante non parla con il modello: avvelena una fonte che il modello consulterà. Un commento in un repository, una recensione di prodotto, i metadati di un documento. Quando l'agente elabora quel contenuto, esegue l'istruzione nascosta come se venisse dall'utente legittimo.

Jailbreak. Tecniche che aggirano le istruzioni di sistema e i filtri di sicurezza per far produrre al modello output che dovrebbe rifiutare. Per un'azienda il rischio non è il contenuto sconveniente in sé, ma il fatto che lo stesso meccanismo che cede sul contenuto cede anche sulle regole operative.

Model evasion. Input costruiti ad arte (gli adversarial examples) che portano il modello a una classificazione sbagliata. Rilevante per chi usa l'AI in controlli automatici: filtri antifrode, moderazione, triage di sicurezza.

Data poisoning. Contaminazione dei dati di addestramento o di fine-tuning, per inserire comportamenti scorretti che si attiveranno dopo. Riguarda chi addestra o mette a punto modelli con dati propri, oppure attinge a dataset esterni non verificati.

Esfiltrazione tramite output. Il modello ha accesso a informazioni sensibili (un database, una knowledge base, lo storico di una conversazione) e viene indotto a riversarle nella risposta. Combinata con la prompt injection, è la via più diretta per una fuga di dati silenziosa.

Il filo comune: un sistema di AI elabora insieme istruzioni fidate e dati non fidati, e fatica a distinguerli. Tutta la difesa nasce da qui.

Difese applicabili, oggi

Non serve riprogettare l'infrastruttura. Servono alcuni controlli messi al posto giusto.

Filtraggio di input e output

Tratta ogni contenuto che entra nel modello, ma non viene da una sorgente fidata, come input non attendibile: posta, pagine web, file caricati, risultati di ricerca. Applica un filtro prima e dopo il modello. In ingresso, isola i dati esterni in sezioni marcate del prompt e istruisci esplicitamente il modello a non eseguire comandi che vi compaiono. In uscita, controlla la risposta prima di mostrarla o inoltrarla: pattern sospetti, dati che non dovrebbero essere lì, chiamate a strumenti non previste.

Isolamento dei tool e privilegi minimi

Un agente con accesso a strumenti (lettura file, query, invio mail, chiamate API) è potente quanto il suo strumento più pericoloso. Concedi a ogni agente solo i tool che gli servono davvero, e a ogni tool solo i permessi minimi. L'agente che redige bozze non ha bisogno di poter inviare. L'agente che legge un database non ha bisogno della scrittura. Le azioni irreversibili (pagamenti, cancellazioni, mail verso l'esterno) restano dietro a una conferma umana.

Logging e tracciabilità

Registra ogni prompt, ogni risposta, ogni chiamata a uno strumento, con timestamp e identità dell'utente. Senza questo livello non puoi indagare un incidente, né dimostrare cosa ha fatto il sistema. È anche il presupposto pratico per qualunque audit. Tieni i log al riparo da chi quei sistemi li usa.

Confini netti fra fiducia e non fiducia

La regola architetturale che vale più di tutte: separa le istruzioni di sistema dai dati esterni, e non lasciare mai che un contenuto non fidato cambi cosa l'agente può fare. Può cambiare cosa l'agente legge, mai i suoi permessi. È lo stesso principio della validazione dell'input nel software tradizionale, applicato a un sistema che, per natura, è progettato per seguire istruzioni.

Governance e AI literacy

La tecnica non basta se non c'è una decisione organizzativa dietro.

Stabilisci una responsabilità. Una persona deve rispondere dell'uso dell'AI in azienda: quali strumenti sono ammessi, su quali dati, con quali limiti. Senza un responsabile, ogni reparto adotta strumenti per conto suo e nessuno ha il quadro.

Documenta. Un registro essenziale degli strumenti di AI in uso: cosa fa ciascuno, a quali dati accede, chi lo ha approvato. È la base sia per la gestione del rischio sia per rispondere a un cliente o a un auditor.

Forma le persone. È l'articolo 4 in pratica. Chi usa questi strumenti deve sapere che il modello può sbagliare con sicurezza, che i dati incollati in un servizio esterno possono lasciare il perimetro aziendale, che un allegato può contenere istruzioni nascoste. La Commissione chiarisce che l'AI literacy va adattata a ruolo, contesto, livello di rischio e competenze delle persone: una formazione breve e concreta vale più di un corso accademico generico.

Questo lavoro non vive isolato. La gestione del rischio AI è un pezzo della gestione del rischio dell'organizzazione: si appoggia sui controlli che già conosci. Se stai lavorando ai controlli dell'Annex A della ISO 27001:2022, l'AI ci rientra in modo naturale. E se la tua azienda è soggetta a NIS2, le misure tecniche e organizzative della checklist di adeguamento NIS2 coprono buona parte di quanto serve anche qui.

Checklist minima per una PMI

Un punto di partenza concreto, ordinabile per priorità:

• Inventario. Elenca gli strumenti di AI in uso, ufficiali e non. Quasi sempre sono più di quelli che immagini.
• Classifica i dati. Per ogni strumento, stabilisci quali categorie di dati può trattare e quali no. Mettilo per iscritto.
• Nomina un responsabile dell'uso dell'AI in azienda.
• Filtra input e output sugli agenti che leggono contenuti esterni o accedono a dati interni.
• Applica i privilegi minimi a ogni agente e a ogni strumento collegato. Le azioni irreversibili passano da una conferma umana.
• Attiva il logging di prompt, risposte e chiamate ai tool, e proteggilo.
• Forma il personale con una sessione breve e pratica sui rischi reali.
• Definisci la risposta agli incidenti: cosa fare se un agente espone dati o si comporta in modo anomalo. Chi avvisare, come isolarlo.
• Rivedi i fornitori: dove vanno i dati che invii a un servizio di AI esterno, per quanto tempo restano, se vengono usati per addestrare modelli.

Fonti principali

• Regolamento (UE) 2024/1689 - AI Act, testo ufficiale EUR-Lex
• Commissione europea - AI literacy, domande e risposte sull'articolo 4
• AI Act Service Desk - articolo 15, accuratezza, robustezza e cybersecurity
• AI Act Service Desk - articolo 50, obblighi di trasparenza

Nessuno di questi punti richiede per forza un budget importante. Richiede una decisione: trattare l'AI come un sistema di produzione, con gli stessi standard di sicurezza che applicheresti a qualunque altro componente che tocca i dati dei tuoi clienti. L'AI Act ha reso esplicita una direzione che era già buona ingegneria: responsabilità, limiti chiari, evidenze e controllo del rischio.