Agente AI ok il giorno della consegna, può smettere di funzionare se nessuno lo mantiene

Un agente AI funziona il giorno della consegna. Dopo sei mesi può non farlo più. Dipende da chi ne risponde e da cosa ha in mano. L’handover è parte del progetto, non un incontro finale¹.

Gli agenti si guastano anche senza modifiche. Il provider del modello può togliere una versione. L’alias su cui ci si affidava può puntare a qualcos’altro. Un’API a monte può rinominare o rimuovere un campo. I documenti che l’agente legge si allontanano da quelli su cui è stato testato: nuovi modelli, nuove sigle degli articoli, un modo diverso di scrivere la stessa cosa. Nulla di questo si vede in code review, perché il codice non è cambiato. Si vede come errore davanti al cliente. Di solito lo nota per primo chi non sa spiegare perché sia successo¹.

Cosa deve uscire insieme al sistema. Primo, un runbook. Deve dire cosa l’agente può fare, cosa non deve mai fare, in quali sistemi può scrivere, e cosa fare quando si comporta in modo strano. Va scritto per la persona di turno, non per chi ha costruito l’agente¹.

Secondo, un evaluation set di proprietà del cliente. Le domande e le risposte attese non devono stare solo sul laptop di chi consegna. Devono stare dove il cliente le può usare e custodire¹.

Terzo, versioni bloccate con possibilità di rollback. Bisogna fissare a cosa punta l’agente e poter tornare indietro se serve. La possibilità di rollback deve esistere insieme al blocco delle versioni¹.

Quarto, un destinatario nominato per gli alert. Gli avvisi devono arrivare a una persona indicata, che sappia di esserlo. Avere un destinatario definito è parte della consegna¹.

Quinto, un decision log leggibile. Serve a capire le scelte fatte e a orientarsi quando si guarda al sistema dopo la consegna. Deve essere comprensibile da chi prende in carico l’agente e da chi fa la guardia¹.

Questi elementi non sono accessori. Decidono se l’agente resta allineato quando cambiano i modelli, le API o i documenti che consulta. Senza, il primo segnale è l’errore in faccia all’utente, non un allarme indirizzato a qualcuno che può intervenire. Con essi, chi è responsabile ha gli strumenti in mano per capire cosa è cambiato attorno all’agente e per agire in modo ordinato¹.

L’indicazione è netta: l’handover non si riduce a una riunione a fine progetto. È una parte del lavoro, con consegne materiali. Runbook, evaluation set del cliente, versioni bloccate con rollback, destinatario degli alert, decision log leggibile. Senza questi pezzi, la manutenzione resta implicita e dipende da chi ha costruito l’agente. Con questi pezzi, la responsabilità è chiara e l’operatività non si spezza alla prima variazione esterna¹.