Governance e sicurezza degli agenti AI: una checklist operativa

Assegna responsabilità osservabili

Il NIST AI Risk Management Framework è un riferimento volontario per integrare considerazioni di affidabilità nella progettazione, nell’uso e nella valutazione dei sistemi AI. Non è un certificato che un progetto ottiene citandolo. Può aiutare a organizzare le domande da porre a chi sviluppa e a chi utilizza il sistema.

Nomina un responsabile del processo e un referente tecnico. Specifica chi approva le fonti, aggiorna le istruzioni e prende in carico gli errori. Scrivi anche chi può sospendere l’agente. La distribuzione delle responsabilità deve essere comprensibile durante una giornata di lavoro, non soltanto nel documento iniziale.

Crea una matrice di dati e azioni

Per ogni strumento elenca cosa può leggere, creare, modificare o inviare. Verifica l’identità con cui si collega ai sistemi e limita il perimetro al compito previsto. Un assistente che cerca procedure non ha automaticamente bisogno di modificare l’archivio o leggere documenti personali dei dipendenti.

OWASP indica, nella voce “Excessive Agency”, che funzionalità, permessi e autonomia eccessivi possono consentire azioni dannose. I controlli devono essere applicati anche dagli strumenti e dai sistemi a valle. Una frase nel prompt che vieta un’operazione non sostituisce il controllo di accesso.

Tratta documenti e messaggi come contenuti esterni

OWASP descrive la prompt injection come un rischio in cui input manipolati alterano il comportamento del modello. Il materiale recuperato da un documento o da un messaggio può contenere istruzioni ostili; il fatto che sia stato trovato tramite ricerca non lo rende attendibile come regola di sistema.

Esempio illustrativo: un allegato a una richiesta contiene una frase che ordina di inviare altrove l’archivio dei clienti. Il sistema deve continuare a trattare l’allegato come dato da analizzare, senza riconoscerlo come autorizzazione. Nelle prove inserisci contenuti di questo tipo in un ambiente controllato e osserva soprattutto se gli strumenti impediscono l’azione.

Conserva evidenze utili a ricostruire gli esiti

Decidi quali eventi servono per capire una pratica: richiesta ricevuta, versione della configurazione, fonti usate, operazioni tentate ed esito dei sistemi. Evita di raccogliere tutto senza uno scopo. I log possono contenere informazioni personali o aziendali e richiedono accessi e tempi di gestione definiti.

Chi verifica un errore dovrebbe distinguere un dato mancante da una risposta errata del modello o da un servizio non disponibile. Collega gli eventi con un identificativo della pratica e mostra gli stati incompleti. Senza questo collegamento, anche molti log possono risultare poco utili al team.

Compliance e HR richiedono un perimetro specifico

Un flusso tracciabile aiuta a ricostruire cosa è accaduto, ma non dimostra da solo la conformità normativa. Quando il progetto tocca dati personali, rapporti di lavoro o decisioni rilevanti per le persone, coinvolgi i responsabili competenti per valutare il caso concreto. Questa checklist riguarda la progettazione tecnica e organizzativa, non sostituisce quella valutazione.

Per un primo assistente HR, puoi circoscrivere la prova a procedure amministrative generali già approvate. Tieni separate le decisioni su candidati o dipendenti, l’accesso ai fascicoli e le pratiche riservate. Stabilisci un canale per contestare o correggere una risposta senza dover convincere il modello che ha sbagliato.

Verifica anche sospensione e ripartenza

Prova un accesso revocato, una fonte ritirata, un documento manipolato e una richiesta ripetuta. Controlla che l’arresto non lasci pratiche invisibili o azioni in corso prive di responsabile. Definisci come il team torna al metodo manuale e come riconcilia il lavoro quando il servizio riprende.

Ripeti le verifiche pertinenti quando cambiano modello, strumenti o dati. Conserva risultati e decisioni insieme alla versione utilizzata: una prova superata su una configurazione precedente non descrive automaticamente quella attuale. Il livello di controllo va rivisto in base alle azioni che il sistema può realmente compiere.

• Responsabile del processo e referente tecnico raggiungibili.
• Dati, azioni e destinatari consentiti documentati.
• Test di accesso e contenuti ostili eseguiti in modo controllato.
• Procedura di sospensione e recupero verificata.
• Revisione prevista dopo cambiamenti significativi.