In breve: consegnate un runbook, un set di valutazione del cliente, versioni fissate con rollback, un responsabile degli avvisi e un registro leggibile.
Un agente AI funziona il giorno della consegna. Che funzioni ancora dopo sei mesi dipende da chi ne risponde e da cosa ha in mano. Il passaggio di consegne fa parte del progetto, non è una riunione finale.
Cosa cambia quando nessuno lo tocca
Gli agenti peggiorano anche senza che nessuno li modifichi. Il fornitore del modello ritira una versione, e l'alias su cui contavate ora punta a qualcos'altro. Un'API a monte rinomina o toglie un campo. I documenti che l'agente legge si allontanano da quelli su cui è stato provato: modelli nuovi, codici articolo nuovi, un modo diverso di scrivere la stessa cosa. Niente di tutto questo compare in una revisione del codice, perché il codice non è cambiato. Compare come un errore davanti a un cliente, di solito notato da qualcuno che non sa perché sia successo.
Cinque cose che escono insieme al sistema
La prima è un runbook. Dice cosa l'agente può fare, cosa non deve mai fare, su quali sistemi può scrivere e cosa fare quando si comporta in modo strano. Scritto per chi è reperibile, non per lo sviluppatore che l'ha costruito.
La seconda è il set di valutazione, di proprietà del cliente. Se le domande e le risposte attese esistono solo sul portatile del fornitore, il cliente non può verificare nulla dopo una modifica. Con il set in mano può rilanciarlo dopo un aggiornamento del modello, una modifica al prompt o un nuovo lotto di documenti, e confrontare con l'ultimo risultato.
La terza sono le versioni fissate, con un rollback scritto. Modello, prompt e indice sono registrati come versioni esatte, e la strada per tornare alla combinazione precedente è un passaggio documentato, non un ricordo.
La quarta è una persona indicata a ricevere gli avvisi, che non sia chi ha costruito il sistema. Un avviso che arriva in una casella che nessuno legge equivale a nessun avviso.
La quinta è il registro delle decisioni, con un modo di leggerlo che non dipenda dal fornitore. Quando qualcuno chiede perché l'agente ha fatto una certa cosa a marzo, la risposta non deve richiedere una telefonata a voi.
A chi arriva il primo messaggio
Pensate al primo avviso di ritiro di un modello. Se set di valutazione e versioni fissate sono in mano al cliente, è una voce di calendario: si pianifica una prova, si confronta, si passa alla nuova versione. Se non lo sono, è un'emergenza che cade su chi ha costruito il sistema, in un momento che non ha scelto. Per una software house è anche un problema di margine, perché l'assistenza informale illimitata raramente è nel prezzo. E se il sistema rientra tra quelli ad alto rischio dell'AI Act, chi lo impiega ha obblighi di sorveglianza sul suo funzionamento: dovrà poterli esercitare senza passare da voi.
La manutenzione è un vincolo di progetto
Un contratto di assistenza aggiunto dopo la consegna non rimedia a un sistema costruito per essere capito solo dai suoi autori. Il vincolo va posto dal primo sprint: cosa potrà far funzionare, controllare e cambiare il cliente senza di noi? Progettare così rende la costruzione un po' più lenta e gli anni successivi molto più tranquilli.
Tra un anno, quando l'agente sbaglia, a chi arriva il primo messaggio?
Testo completo: la checklist completa del passaggio di consegne
Articolo originale: https://www.omarbaruzzo.it/it/blog/agente-ai-dopo-la-consegna
