Sicurezza degli agenti AI: monitoraggio, autorizzazioni e approvazione umana

B2Shift · Pubblicato il 27 agosto 2026 · Aggiornato il 27 agosto 2026

Un agente AI in grado di eseguire azioni, non solo di generare testo, eredita i requisiti di sicurezza di qualunque cosa sia connesso, oltre ad alcuni dei propri. La maggior parte degli incidenti sono riconducibili ad un accesso troppo ampio, non al modello stesso.

L'accesso con privilegi minimi è il controllo che conta di più

Un agente deve mantenere la propria identità e le proprie autorizzazioni con ambito, mai le credenziali prese in prestito da un amministratore. Concedi solo i sistemi e i campi richiesti dall'attività specifica. L'ampliamento successivo dell'accesso costituisce una modifica della configurazione; scoprire che un agente ha avuto accessi non necessari dopo un anno di funzionamento è un problema di controllo, non una soluzione rapida.

Dividere le azioni in base alla reversibilità, non a quanto sembrano impressionanti

La lettura, la stesura, la classificazione e lo smistamento possono solitamente essere eseguiti senza supervisione. Inviare denaro, pubblicare un prezzo, rispondere a un reclamo a tuo nome o eliminare un record meritano un cancello di approvazione umana o almeno una finestra di ritardo in cui una persona può intervenire. Trattare ogni azione allo stesso modo limita eccessivamente i casi utili o sottolimita quelli pericolosi.

Monitora la deriva, non solo il tempo di attività

Un agente può essere tecnicamente online e avere torto: rispondendo con conoscenze obsolete, classificando erroneamente una quota crescente di richieste o andando alla deriva al di fuori dell'ambito previsto man mano che i sistemi a monte cambiano. Il monitoraggio deve tenere traccia della qualità dell’output e delle tendenze di fiducia, non solo se il servizio risponde.

Rendi ricostruibile ogni decisione

Ogni azione dovrebbe registrare ciò che l'ha attivata, quale contesto ha utilizzato, cosa ha deciso, la sua sicurezza, se un essere umano l'ha approvata e cosa è cambiato di conseguenza. La OWASP Top 10 per le applicazioni LLM documenta le classi di errore più comuni (agenzia eccessiva, gestione dell'output non sicura, inserimento tempestivo) che vale la pena verificare il progetto prima del lancio.

La gestione della fiducia è un percorso progettato, non un ripensamento

I casi con scarsa certezza dovrebbero avere una destinazione esplicita: una persona nominata o una coda di revisione, mai un'ipotesi migliore silenziosa. La modalità di fallimento che desideri è "questo è andato a un essere umano"; quello contro cui stai progettando è "questo è andato storto e nessuno se ne è accorto per tre settimane". Vedi Agenti AI/Dipendenti AI per sapere come tutto questo viene inserito in una build e Come mantenere l'automazione AI sicura e conforme al GDPR per la metà della protezione dei dati di questa immagine.