Sicurezza, identità e governance degli agenti AI

C’è una sequenza ricorrente nei progetti di AI agentiva enterprise: un prototipo funzionante viene costruito in poche settimane, dimostra valore sul caso d’uso scelto e convince il management ad andare avanti. Poi inizia la fase di messa in produzione, e i tempi si allungano in modo imprevisto. I problemi che emergono riguardano la sicurezza degli accessi, la tracciabilità delle azioni, la conformità ai requisiti normativi, la sostenibilità operativa nel tempo. Sono tutti aspetti che nel prototipo erano stati rimandati e che in produzione non possono più esserlo.

Questo articolo analizza le tre aree tecniche che più frequentemente determinano questa difficoltà di transizione:

• la gestione dell’identità degli agenti,
• i meccanismi di tracciabilità e osservabilità,
• la governance operativa dei modelli attraverso le pratiche LLMOps.

Identità digitale degli Agent AI: come gestirla in sicurezza

Nei sistemi informativi tradizionali la distinzione tra utenti umani e servizi applicativi è consolidata: ciascuno ha credenziali proprie, ruoli definiti e un ciclo di vita gestito in modo indipendente. Quando si introducono gli agenti AI, questa separazione viene spesso ignorata, con conseguenze concrete. L’errore più frequente è far operare gli agenti con le credenziali di un utente umano — un account di servizio generico o, nei prototipi, le credenziali dello sviluppatore. Questo approccio rende impossibile distinguere nei log di sistema le azioni dell’agente da quelle dell’utente, assegna all’agente permessi più ampi del necessario, e lega il ciclo di vita del sistema a quello delle persone che lo hanno costruito.

La soluzione è registrare ogni agente come service principal nei sistemi di Identity and Access Management aziendali — Azure Active Directory, Okta o equivalenti — con credenziali proprie, scadenze di rotazione delle chiavi e procedure di revoca esplicite. Le credenziali non devono mai essere hardcoded nel codice o nei prompt: vanno gestite tramite secret manager (Azure Key Vault, HashiCorp Vault, AWS Secrets Manager) con accesso auditato.

Il modello di autorizzazione deve essere calibrato sul principio del minimo privilegio: ogni agente riceve esattamente i permessi necessari per svolgere il suo compito. Un agente classificatore di ticket ha bisogno di accesso in lettura al CRM, non in scrittura. Un agente che genera bozze di risposta non ha bisogno di accedere ai sistemi di billing. Costruire questo modello richiede una mappatura preliminare dei flussi agente — per ogni agente, quali API chiama, su quali oggetti opera, quali azioni esegue — e solo da questa mappatura si può derivare un set di permessi sensato.

Oltre ai permessi standard, un sistema maturo implementa limiti operativi specifici per il contesto AI: soglie sul numero di operazioni eseguibili in un intervallo di tempo, limiti sugli importi per operazioni finanziarie, restrizioni sulle azioni disponibili fuori da certi contesti. Questi limiti riducono il rischio operativo di comportamenti anomali o inattesi degli agenti indipendentemente dalla qualità del modello che li governa.

In un sistema enterprise, ogni azione eseguita da un agente — una chiamata API, una modifica a un record, l’invio di una comunicazione, una decisione di routing — deve essere registrata in modo strutturato e immutabile. Il log deve includere quale agente ha eseguito l’azione, con quale identità, in quale timestamp, su quale risorsa, con quale input e quale output, e in risposta a quale evento scatenante. Questo livello di tracciabilità serve a tre scopi concreti: il debugging operativo (ricostruire cosa è successo quando un flusso produce un risultato inatteso), l’audit di conformità (dimostrare che un’azione automatizzata è avvenuta secondo procedure definite, requisito normativo in settori regolamentati) e la gestione delle contestazioni contrattuali.

LLM Observability e LLOps per gestire agenti AI in produzione

Oltre alla tracciabilità delle azioni, un sistema maturo monitora il comportamento dei modelli LLM in modo continuativo. Gli strumenti di LLM observability — LangSmith, LangFuse e equivalenti — registrano per ogni chiamata al modello il prompt inviato, la risposta ricevuta, la latenza, il numero di token consumati e il costo associato. Questi dati servono principalmente a rilevare due fenomeni critici: il drift, ovvero la degradazione progressiva della qualità delle risposte nel tempo, e le allucinazioni sistematiche, ovvero pattern di errore ricorrenti che il monitoraggio spot non rileva ma che emergono nell’analisi aggregata. Un aggiornamento silenzioso del modello da parte del provider, un cambiamento nella distribuzione degli input, una knowledge base che non viene aggiornata a fronte di policy modificate: sono tutti eventi che il monitoraggio continuativo intercetta prima che producano conseguenze operative rilevanti.

Il termine LLMOps descrive l’insieme di pratiche e strumenti necessari per gestire modelli e agenti AI in produzione in modo stabile nel tempo. Tre aspetti meritano attenzione specifica.

Il primo riguarda il monitoraggio della qualità. A differenza del software tradizionale, un sistema agente non fallisce in modo binario: produce output di qualità variabile in modo non sempre prevedibile. Servono metriche definite per ogni caso d’uso — tasso di classificazione corretta, percentuale di flussi completati senza intervento umano, tempo medio di risoluzione, frequenza di rifiuto dei risultati da parte degli operatori in revisione — e dashboard che le rendano visibili in modo continuativo.

Il secondo riguarda il versioning di modelli e prompt. I fornitori di LLM aggiornano i loro modelli con cadenza regolare, e un aggiornamento può modificare il comportamento del sistema in modo imprevisto senza che venga cambiata una riga di codice. Un sistema enterprise deve versionalizzare sia i modelli utilizzati sia i prompt che li governano, con la possibilità di eseguire rollback rapido in caso di regressione rilevata. La stessa logica si applica alle pipeline RAG: se la knowledge base cambia — nuovi documenti, policy aggiornate, dati revisionati — il comportamento degli agenti che dipendono da essa può cambiare in modo non controllato in assenza di un sistema di versioning.

Il terzo riguarda il controllo dei costi. In un sistema multi-agente con flussi complessi, il consumo di token può diventare rilevante in modo inaspettato. Un prompt mal costruito che include contesto non necessario, un agente che chiama il modello più volte del necessario, una knowledge base che restituisce chunk troppo grandi nelle query RAG: sono pattern che impattano i costi in modo silenzioso ma cumulativo. Il controllo dei costi richiede visibilità granulare — consumo per agente, per tipo di task, per flusso, per periodo — per identificare le inefficienze prima che diventino un problema di budget.

In conclusione, sicurezza, identità, tracciabilità e governance sono dimensioni progettuali che devono essere affrontate in parallelo allo sviluppo del sistema, non in sequenza. Questo non significa che un prototipo debba avere la stessa solidità di un sistema in produzione: significa che le scelte architetturali fatte durante la sperimentazione devono essere compatibili con i requisiti che il sistema dovrà soddisfare quando sarà operativo.