La policy aziendale per gli agenti AI: struttura e regole essenziali

Una policy per l'uso degli agenti AI in azienda deve rispondere a quattro domande: quali agenti sono ammessi e su quali sistemi, cosa possono proporre, chi approva gli interventi e quali tracce restano di ogni decisione. Questo articolo propone una struttura pronta da adattare, con i punti che non conviene lasciare impliciti: perimetro delle proposte, approvazioni, fonti autorizzate e registrazioni.

Perché serve una policy prima degli agenti

Un agente AI che osserva i sistemi e propone interventi tocca temi già regolati in azienda: accessi, dati personali, modifiche alle configurazioni, conservazione delle evidenze. Se il regolamento esistente non nomina gli agenti, ogni caso nuovo viene deciso a voce e le decisioni si disperdono. Una policy dedicata non sostituisce le policy di sicurezza e privacy già in vigore: le richiama e aggiunge le regole specifiche per sistemi che propongono azioni.

Il NIST AI Risk Management Framework, nella versione 1.0 attuale, è un riferimento volontario per incorporare l'affidabilità dei sistemi AI nei processi dell'organizzazione: non è una legge né una certificazione, ma offre uno schema per ragionare su governance, rischi e misure. Il profilo dedicato all'AI generativa (NIST-AI-600-1, luglio 2024) aiuta inoltre a identificare i rischi specifici di questi sistemi. Una policy aziendale può appoggiarsi a questi riferimenti senza citarli come obblighi.

Struttura della policy: le sezioni che non devono mancare

La tabella seguente riassume una struttura utilizzabile. Ogni sezione va compilata con i nomi, i sistemi e i ruoli della tua azienda; le voci in forma di domanda sono quelle che il documento deve chiudere senza ambiguità.

Cosa gli agenti possono proporre e cosa no

È il punto più delicato della policy e quello che si presta meno alle formule generiche. Conviene lavorare su tre liste:

• Osservazione libera. Letture e monitoraggi che non modificano nulla: lo stato di un servizio, l'esito di un backup, una variazione di configurazione rilevata nelle fonti collegate.
• Proposta con approvazione. Interventi attivi che l'agente può preparare e spiegare, ma che partono solo dopo la decisione della persona prevista: un ripristino di configurazione, la disattivazione di un account, l'avvio di una procedura documentata.
• Fuori perimetro. Ciò che l'agente non deve né proporre né eseguire, indicato in modo esplicito: per esempio valutazioni sul comportamento delle persone, accessi a dati non autorizzati, modifiche a sistemi dichiarati sensibili. Sui temi di legge vale la valutazione del consulente: un uso interno agli allarmi di rete non è, di norma, un sistema ad alto rischio per il Regolamento europeo sull'intelligenza artificiale (AI Act), mentre applicazioni che valutano i dipendenti possono essere vietate o soggette a obblighi stringenti. Il perimetro va verificato caso per caso: ne parliamo nelle FAQ su AI Act e agenti aziendali.

La classificazione dettagliata degli interventi, con i livelli di approvazione, merita un documento a sé: ne parliamo nell'articolo su quali azioni devono richiedere un'approvazione. Per le regole sugli accessi degli agenti ai sistemi, il riferimento interno è l'articolo sui privilegi minimi per gli agenti AI.

Allineare la policy a privacy e sicurezza esistenti

La policy degli agenti non riparte da zero. Tre controlli la tengono coerente con ciò che esiste già:

• Richiamo esplicito. La policy cita il regolamento per l'uso degli strumenti informatici, l'informativa privacy dei dipendenti e le procedure di gestione degli accessi. Se un agente tratta registri che contengono dati personali, valgono le regole già stabilite con il responsabile della protezione dei dati.
• Nessuna scorciatoia. Un'approvazione raccolta tramite agente non vale meno, ma nemmeno più, di una approvata dal canale precedente. Chi prima non poteva autorizzare un intervento non può farlo ora perché lo propone un agente.
• Evidenze compatibili. Le registrazioni prodotte dagli agenti devono poter entrare nei processi esistenti di audit e di gestione degli incidenti, non vivere in un archivio separato e incomprensibile. Ne parliamo nell'articolo sulla tracciabilità delle azioni degli agenti.

Esempio illustrativo: la policy alla prova di un account fornitore

Esempio illustrativo. Lo scenario seguente è inventato e non racconta un caso reale di un cliente OverZeus.

Una cooperativa di trasporti adotta la sua prima policy per gli agenti AI. Nella sezione sulle proposte scrive che la disattivazione degli account dei fornitori appartiene alla lista «proposta con approvazione», con approvatore unico il responsabile IT, e che le fonti consultabili dagli agenti sono il registro contratti e il gestionale accessi, entrambi approvati dal proprietario del processo.

Un mese dopo l'agente segnala che l'account di un corriere convenzionato è ancora attivo, mentre nel registro contratti la convenzione risulta scaduta. La proposta arriva al responsabile IT con le fonti visibili: la voce del registro e i permessi attuali dell'account. Il responsabile verifica che la scadenza sia reale — il contratto è in rinnovo, firmato la settimana prima ma non ancora registrato — e rifiuta la disattivazione, annotando il motivo. La policy aveva previsto esattamente questo: la proposta era ammessa, la fonte era quella giusta, ma la decisione e la sua motivazione restano alla persona, e il rifiuto viene registrato come le approvazioni.

Il caso mostra anche cosa sarebbe successo senza policy: nessun elenco di fonti approvate, nessun obbligo di registrare il rifiuto, e la tentazione di trattare il silenzio del responsabile come un consenso.

Come OverZeus rende applicabili queste regole

Una policy funziona se il sistema la fa rispettare anche quando nessuno la sta rileggendo. In OverZeus due agenti coprono i punti più critici:

• Themis applica privilegi, approvazioni e limiti operativi attraverso controlli esterni al modello AI: un intervento che arriva con un'autorizzazione scaduta o fuori perimetro viene bloccato dal controllo, non dalla buona volontà del modello.
• Nestor recupera manuali, runbook e casi precedenti rispettando i permessi, e rimanda alle fonti aziendali approvate: la lista «fonti autorizzate» della policy diventa l'elenco effettivo di ciò che l'agente può consultare. Quando due documenti si contraddicono, Nestor evidenzia le differenze e chiede la revisione al proprietario del documento; non aggiorna le procedure da solo.

Le approvazioni seguono il modello «l'agente propone, la persona decide»: l'assenza di risposta non autorizza l'intervento, coerentemente con la clausola che la policy deve scrivere in forma esplicita. Le decisioni, comprese quelle di attendere, restano nelle evidenze conservate dal sistema.

Aggiornamento, formazione e sanzioni interne

Tre clausole chiudono il documento e ne decidono la durata:

• Riesame programmato. La policy indica un proprietario e un momento di riesame, oltre alla regola che ogni modifica sostanziale degli agenti — nuova versione, nuove integrazioni, nuovo perimetro — apre una revisione straordinaria. Su questo punto vedi l'articolo su quali verifiche ripetere quando si aggiorna un agente.
• Formazione. Chi approva gli interventi deve sapere cosa sta autorizzando: la policy prevede un'istruzione minima per approvatori e referenti, distinta dalla formazione tecnica degli amministratori.
• Violazioni. Le conseguenze per chi aggira le regole — per esempio usando le credenziali di un collega per approvare — vanno rinviate al regolamento aziendale e alla disciplina già esistente, senza creare un sistema sanzionatorio parallelo.

Una policy breve, applicata e aggiornata vale più di un documento completo che nessuno riesamina. Parti dalle sezioni della tabella, adattale ai tuoi sistemi e falle leggere a chi gestisce privacy e sicurezza prima dell'adozione.

Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.

Tutti gli articoli OverZeus