Agenti AI in azienda: chi risponde quando l’automazione sbaglia

Dai copilot che suggeriscono testo agli agenti che eseguono azioni: cambia la superficie d’attacco, cambiano i controlli, cambia la domanda chiave. Non è “quanto è intelligente il modello?”, ma “chi risponde quando sbaglia?”

Negli ultimi due anni molte organizzazioni hanno iniziato con strumenti “assistivi”: riassunti automatici, bozze di email, ricerca documentale interna. È stato un primo passo sensato: basso rischio, alto ritorno sulla produttività, poche integrazioni complesse da gestire.

Oggi però stiamo entrando in una fase profondamente diversa: gli agenti AI non si limitano più a suggerire, ma agiscono autonomamente. Aprono casi nel sistema di ticketing, aggiornano record nei CRM, generano report finanziari, avviano workflow approvativi, inviano comunicazioni a clienti e partner, orchestrano strumenti e API aziendali.

Questa evoluzione cambia la sicurezza informatica in modo strutturale. Un agente AI non è solo un pezzo di software: è un attore operativo inserito nei processi aziendali, con accesso privilegiato a dati sensibili e sistemi critici. E come ogni attore operativo va governato, auditato e “responsabilizzato” attraverso regole chiare e verificabili.

Perché gli agenti AI rappresentano un rischio (anche quando funzionano bene)

Il punto critico non è solo che i modelli linguistici possono “allucinare” risposte sbagliate (problema che certamente persiste). Il vero salto qualitativo nel profilo di rischio nasce dalla combinazione di due elementi:

• Agency: l’agente ha la capacità concreta di compiere azioni attraverso tool, connettori e chiamate API
• Identity: l’agente agisce “come qualcuno”, utilizzando credenziali autentiche, token di accesso, consensi OAuth

Quando agency e identity si incontrano, l’agente diventa di fatto un insider automatizzato. Se lo configuri male, se qualcuno lo inganna attraverso prompt injection, o se un attaccante riesce a ottenere consensi OAuth e token di accesso, il danno non si limita a “una risposta sbagliata in chat”: diventa un’azione sbagliata eseguita con permessi reali sui sistemi aziendali.

Casi recenti documentati lo dimostrano chiaramente. Campagne di attacco come CoPhish hanno sfruttato social engineering e meccanismi di OAuth consent per rubare token e accedere a caselle email, file condivisi e dati tenant. Vulnerabilità come Reprompt hanno mostrato come un semplice click su un link possa trasformarsi in una prompt injection con conseguente esfiltrazione di dati.

Governance: trattare l’agente come un servizio critico, non come un gadget

Una governance efficace parte da una regola brutalmente semplice: nessun agente va in produzione se non ha un owner nominativo. Niente “agenti orfani” gestiti informalmente da team di innovazione senza responsabilità definite.

Un modello di governance pratico, leggero ma robusto, si articola su tre livelli complementari:

AI policy aziendale

Definisce i confini strategici: casi d’uso consentiti e vietati, classificazione delle classi di rischio, tipologie di dati proibiti, regole sulla scelta di modelli e fornitori, requisiti minimi per l’audit trail.

AI risk & safety operations

Traduce le policy in controlli operativi concreti: gestione delle identità digitali, assegnazione granulare dei permessi, logging strutturato, valutazioni di sicurezza pre-produzione, monitoraggio continuo, procedure di gestione degli incidenti, processo di gestione delle eccezioni.

Agent owners chiaramente identificati

Il business owner risponde del “cosa” (processo aziendale e impatti sul business), il technical owner risponde del “come” (architettura tecnica, integrazioni, implementazione dei controlli di sicurezza).

Qui possono aiutare framework di riferimento già consolidati come ISO/IEC 42001 per i sistemi di gestione dell’intelligenza artificiale e il NIST AI Risk Management Framework, che fornisce strumenti per mappare, misurare, gestire e governare sistematicamente i rischi legati all’AI.

Il contesto normativo italiano ed europeo: non solo compliance formale

Il Regolamento europeo sull’intelligenza artificiale (AI Act) prevede un’applicazione generale a partire dal 2 agosto 2026, con anticipazioni significative già dal 2 febbraio 2025 per quanto riguarda i divieti e le disposizioni di carattere generale.

Sul fronte della cybersecurity, la Direttiva NIS2 è stata recepita in Italia con il D.Lgs. 138/2024, entrato in vigore il 16 ottobre 2024, che eleva significativamente le aspettative su governance della sicurezza, gestione strutturata del rischio e resilienza operativa delle organizzazioni.

Il punto sostanziale è questo: anche senza entrare nel dettaglio puntuale degli obblighi normativi, AI Act e NIS2 convergono nella stessa direzione strategica: processi documentati, controlli verificabili, evidenze tracciabili e dimostrabili.

Audit sugli agenti AI: cosa devi poter dimostrare (senza inventarlo a posteriori)

Un audit efficace sugli agenti AI non dovrebbe partire dalla valutazione teorica del modello, ma dall’analisi dell’operatività concreta. Tipicamente un auditor chiederà di dimostrare:

• Inventario completo degli agenti (produzione e pre-produzione), con owner, scopo aziendale, livello di criticità, tipologie di dati trattati
• Valutazione del rischio documentata e criteri espliciti di classificazione (basso/medio/alto impatto)
• Permessi e connettori: chi può fare cosa, con quali scope di accesso, attraverso quale processo di approvazione
• Logging completo e strutturato: prompt ricevuti, risposte generate, chiamate a tool esterni, dati letti e scritti, decisioni automatiche, escalation a supervisori umani
• Change management: versioning delle configurazioni, approvazioni formali, capacità di rollback, test di sicurezza pre-rilascio
• Incident response: runbook operativi, kill switch testati, evidenze di simulazioni periodiche e metriche sui tempi di risposta
• Privacy by design: minimizzazione dei dati, policy di retention, basi giuridiche del trattamento e, quando necessario, Data Protection Impact Assessment

La frase che spesso “sblocca” la mentalità corretta in questo ambito è: non basta che l’agente sia utile; deve essere anche completamente ricostruibile in ogni sua azione e decisione.

Sicurezza operativa: i controlli tecnici che fanno davvero la differenza

L’approccio OWASP ha già identificato vulnerabilità tipiche dei Large Language Model: prompt injection, gestione insicura degli output, data leakage, rischi nella supply chain. Per gli agenti autonomi serve però aggiungere un livello critico: il potenziale abuso degli strumenti a cui l’agente ha accesso.

I 10 controlli minimi per agenti “con le mani sui sistemi”

1. Identità forte e centralizzata: Single Sign-On, Conditional Access basato su policy, autenticazione multi-fattore, device compliance verificata.
2. Least privilege sui tool: permessi minimi necessari per ogni connettore, scope API ristretti al necessario, nessun accesso “global read/write” concesso per comodità operativa.
3. Segregazione rigorosa degli ambienti: sviluppo, test e produzione completamente separati, con credenziali e token distinti.
4. Secret management professionale: token e chiavi API gestiti in vault dedicati, rotazione programmata, capacità di revoca rapida.
5. Egress control: allowlist esplicita di domini e API endpoint verso cui l’agente può inviare dati.
6. DLP e classificazione: blocchi automatici su PII e dati sensibili, policy granulari per gestione di allegati e link esterni.
7. Human-in-the-loop mirato: approvazione umana obbligatoria per azioni ad alto impatto aziendale (invii verso destinatari esterni, cancellazioni massive, autorizzazioni di pagamento, modifiche a sistemi core).
8. Kill switch e procedure break-glass: capacità di stop immediato dell’agente con revoca contestuale delle credenziali, procedure testate regolarmente.
9. Osservabilità strutturata: log machine-readable con alert automatici su comportamenti anomali (picchi anomali di export dati, sequenze insolite di chiamate a tool, pattern riconducibili a prompt injection).
10. Valutazioni pre-produzione: test di sicurezza specifici (simulazioni di prompt injection, scenari di tool misuse) da affiancare ai normali test funzionali.

Responsabilità: il modello RACI che evita lo scaricabarile organizzativo

Per ogni agente in produzione, definire responsabilità esplicite non è un esercizio burocratico ma una componente essenziale della sicurezza. Un modello RACI minimale ma efficace prevede:

• Accountable (Business owner): definisce obiettivi di business, valuta impatti sul processo, stabilisce criteri di correttezza, progetta fallback umani quando necessario.
• Responsible (Technical owner): progetta architettura e integrazioni, implementa controlli di sicurezza, configura logging e osservabilità.
• Consulted (Data owner): definisce policy di accesso ai dati, garantisce qualità e accuratezza, stabilisce retention period.
• Consulted/Approver (CISO/Security operations): valida controlli di sicurezza, approva permessi, coordina incident response.
• Consulted/Approver (DPO/Legal): verifica compliance privacy, rivede contratti con fornitori, valuta trasferimenti di dati.
• Informed (Internal audit): pianifica verifiche periodiche e campionamenti su configurazioni e log.

È sorprendente quanto questo semplice framework organizzativo riduca i buchi di responsabilità che poi si trasformano inevitabilmente in vulnerabilità tecniche.

10 domande che ogni organizzazione dovrebbe porsi prima di mettere un agente in produzione

1. Questo agente ha un owner nominativo e responsabile?
2. Quali dati può vedere, e quali dati non deve assolutamente vedere?
3. Quali azioni può compiere autonomamente, e quali azioni sono esplicitamente vietate?
4. Con quali credenziali opera? I token dove sono conservati? Come possiamo revocarli immediatamente?
5. I permessi assegnati sono verificati e ridotti al minimo necessario?
6. Possiamo ricostruire esattamente cosa è successo attraverso log completi e consultabili?
7. Abbiamo testato resistenza a prompt injection e scenari di tool misuse?
8. Per le azioni critiche esiste un meccanismo di approvazione umana o doppia conferma?
9. Se qualcosa va storto, abbiamo un kill switch testato e funzionante?
10. Sappiamo dimostrare tutto questo in sede di audit interno o ispettivo?

La maturità organizzativa non si misura in “più agenti”, ma in “agenti governabili”

La traiettoria tecnologica è ormai chiara: gli agenti AI diventeranno un layer normale e pervasivo dell’operatività digitale aziendale. L’errore strategico sarebbe gestirli come sperimentazione continua e destrutturata, senza disciplina ingegneristica.

Il vero passaggio di maturità consiste nel costruire una vera e propria “factory di agenti” con regole ripetibili e scalabili: lifecycle management strutturato, controlli standard, audit pack predefiniti, responsabilità chiaramente assegnate.

È precisamente qui che la sicurezza informatica smette di essere un freno e diventa un acceleratore strategico: abilita l’adozione consapevole, previene incidenti costosi in termini economici e reputazionali, e soprattutto rende l’innovazione tecnologica sostenibile nel medio-lungo periodo.

Come diceva il CISO di una grande banca italiana in un recente confronto: “Non vogliamo rallentare l’AI. Vogliamo solo che tra sei mesi, quando qualcosa andrà storto, sappiamo esattamente chi chiamare e cosa guardare nei log“.

È questa la differenza tra sperimentazione e produzione. Ed è questa la sfida che le organizzazioni italiane ed europee devono affrontare nei prossimi mesi, mentre AI Act e NIS2 alzano progressivamente l’asticella delle aspettative normative e di mercato.

Il prossimo passo? Agenti che monitorano gli agenti

Si tratta di passare da “point-in-time audit” a “continuous AI oversight“. L’idea di base è questa: invece di auditor umani che setacciano manualmente dati e configurazioni, sistemi AI possono monitorare proattivamente requisiti di compliance ed evidenziare aree critiche.

Zenity, uno degli emergenti, rileva rischi di compliance, impone guardrail, monitora attività degli agenti e automatizza reporting per garantire allineamento continuo con standard regolatori.

Il paradosso? Usiamo AI per scalare la governance, ma questo introduce nuovi rischi di governance che richiedono… più governance.

Ma direi che di questo ne parleremo in un altro articolo…