Quando arriva una nuova versione del modello o cambia la configurazione di un agente AI, le proposte operative possono cambiare anche se i sistemi osservati sono gli stessi. Prima di riattivare gli interventi servono tre passaggi: capire che cosa è cambiato davvero, riprovare l'agente su casi rappresentativi con esito noto e riconfermare permessi, limiti e approvazioni, registrando la decisione di rilascio. Questo articolo organizza il processo come un obbligo organizzativo dell'azienda, non come una funzione automatica del prodotto.
Versione, configurazione, fonti: tre cambiamenti diversi
«Abbiamo aggiornato l'agente» può voler dire cose molto diverse, e ognuna chiede verifiche proprie:
- Nuova versione del modello. Cambia il modo in cui l'agente legge i segnali e formula le proposte. Un caso che ieri produceva una raccomandazione può produrne una diversa, più cauta o più decisa.
- Nuova configurazione. Soglie, perimetro, integrazioni, elenchi di sistemi osservati: il modello è lo stesso, ma cambia ciò che l'agente vede e può proporre.
- Nuove fonti consultate. Un nuovo registro, un manuale aggiornato, un inventario diverso: le proposte cambiano perché cambiano le informazioni su cui si fondano.
La prima verifica è documentale: il responsabile deve poter dire quale di questi tre piani è cambiato, con quale versione precedente confrontarlo e chi ha richiesto la modifica. Se il fornitore non fornisce note di rilascio leggibili, questo va segnalato come problema di governance, non assorbito in silenzio.
Il NIST AI Risk Management Framework, riferimento volontario per gestire i rischi dei sistemi AI lungo il loro ciclo di vita, tratta il monitoraggio e la gestione del cambiamento come parte ordinaria dell'uso dell'AI, non come un'eccezione: un aggiornamento non è la fine del controllo, ma un momento in cui il controllo va rieseguito.
Le verifiche da ripetere prima del rilascio
La tabella seguente organizza i controlli. Non è una procedura del prodotto: è uno schema che l'azienda adotta e adatta, con responsabilità e tempi propri.
| Verifica | Come si svolge | Evidenza da conservare |
|---|---|---|
| Confronto su casi noti | Si ripropongono all'agente aggiornato casi rappresentativi già osservati, con esito documentato, e si confrontano le proposte con quelle della versione precedente. | Elenco dei casi, proposte delle due versioni, differenze rilevanti. |
| Casi di confine | Si verificano le situazioni in cui l'agente deve non agire: fonte mancante, dato contraddittorio, autorizzazione scaduta. | Esito atteso e osservato per ciascun caso. |
| Permessi e integrazioni | Si riconfermano gli accessi dell'agente ai sistemi e ai documenti: nessun permesso in più rispetto a quelli approvati, nessuna integrazione nuova non valutata. | Elenco dei permessi effettivi confrontato con quelli autorizzati. |
| Limiti di esecuzione | Si verifica che i controlli esterni al modello — quelli che bloccano un intervento fuori perimetro o senza approvazione valida — funzionino anche con la nuova versione. | Esito del test di blocco su un intervento non autorizzato, condotto in un ambiente che non tocca la produzione. |
| Approvazioni e durata | Si verifica che le regole di approvazione siano rimaste quelle definite: chi approva cosa, con quale durata dell'autorizzazione. | Confronto con la policy interna e con le deleghe in vigore. |
| Piano di ripristino | Si definisce in anticipo come tornare alla versione o alla configurazione precedente, e in quali condizioni farlo. | Procedura di ripristino verificata, con responsabile e tempi. |
Due avvertenze su queste verifiche. La prima: un confronto su casi noti misura la coerenza delle proposte, non garantisce il comportamento su casi mai visti; la fase di osservazione dopo il rilascio resta necessaria. La seconda: la frequenza e la profondità dei controlli dipendono da rischio, criticità dei sistemi e obblighi applicabili — vanno concordate nella policy, non copiate da una regola universale.
Esempio illustrativo: la nuova versione cambia una priorità
Esempio illustrativo. Lo scenario seguente è inventato e non racconta un caso reale di un cliente OverZeus.
Una rete di laboratori di analisi usa un agente per osservare i propri sistemi e proporre interventi. Arriva una nuova versione del modello. Prima del rilascio, il responsabile IT estrae dalle evidenze conservate venti casi rappresentativi degli ultimi mesi — un backup non riuscito, un privilegio modificato, un dispositivo nuovo in inventario — e li sottopone alla versione aggiornata in un ambiente di prova che non esegue interventi sulla produzione.
In diciannove casi le proposte coincidono con quelle registrate all'epoca. Nel ventesimo, il caso del backup, la nuova versione propone di attendere un secondo fallimento prima di segnalare, mentre la precedente proponeva la verifica immediata. La differenza non è necessariamente un errore, ma cambia il rischio accettato dall'azienda: il responsabile riesamina la soglia con il proprietario del processo e decide di mantenere la segnalazione immediata impostandola in configurazione. Solo dopo questa decisione, e dopo aver riconfermato permessi e limiti, il rilascio viene approvato per iscritto, con la procedura di ripristino allegata: se nei primi giorni le proposte si discostano oltre una soglia concordata, si torna alla versione precedente.
Il punto non è la soglia scelta — è un'altra azienda potrebbe decidere diversamente — ma il fatto che la differenza sia emersa prima del rilascio e che la decisione abbia un nome, un motivo e una condizione di ritorno.
Il contributo di OverZeus alla gestione degli aggiornamenti
In OverZeus tre agenti coprono passaggi distinti di questo processo:
- Oracle è l'agente della modalità di sola osservazione: nella fase di prova osserva e prepara proposte senza modificare la produzione. La stessa logica — vedere cosa proporrebbe il sistema prima di autorizzarlo — è il criterio con cui organizzare la verifica di un aggiornamento su casi concordati.
- Themis applica privilegi, approvazioni e limiti operativi con controlli esterni al modello AI: la verifica che questi controlli reggano anche dopo l'aggiornamento è ciò che impedisce a una nuova versione di ereditare fiducia non meritata.
- Mnemosyne conserva fonti, timeline, proposte, autorizzazioni ed esiti: è ciò che rende possibile il confronto tra versioni su casi realmente accaduti e la registrazione della decisione di rilascio o di rinvio.
Le integrazioni, i registri di versione e le modalità di ripristino supportate vanno confermati per il progetto specifico: la tabella di questo articolo resta un requisito organizzativo dell'azienda, qualunque sia lo strumento.
Approvare, rinviare o tornare indietro: la decisione documentata
Il rilascio di un aggiornamento deve chiudersi con una decisione esplicita, non con un'installazione. La decisione contiene almeno quattro elementi: chi ha verificato, quali differenze sono emerse e come sono state risolte, chi approva il rilascio, in quali condizioni si torna alla configurazione precedente. Anche il rinvio — «non adottiamo questa versione perché» — è una decisione da registrare: evita che la stessa valutazione venga rifatta da zero alla versione successiva.
Le autorizzazioni concesse agli interventi non sopravvivono automaticamente all'aggiornamento: un'approvazione data per un comportamento osservato non copre un comportamento diverso. Su questo punto vedi gli articoli sulla durata delle autorizzazioni e sulla tracciabilità delle azioni degli agenti; per i casi in cui l'agente deve fermarsi invece di agire, l'articolo sulla gestione dell'errore. Il quadro generale delle regole resta la policy aziendale per gli agenti AI, che dovrebbe dichiarare l'aggiornamento come evento che apre una revisione.
Vuoi vedere come cambia una proposta prima di autorizzarla in produzione? Guarda come vengono presentati e autorizzati gli interventi degli agenti.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.