AI 智能體交付後由誰負責維護?
Chi mantiene l'agente dopo la consegna?
文章指出,AI 智能體交付後能否持續運作,取決於責任歸屬,以及客戶能否取得必要的維護資料。交接應包括操作手冊、由客戶持有的評測集、固定版本及書面回滾步驟、指定警報接收人,以及可獨立閲讀的決策紀錄。若客戶持有評測集和版本資訊,模型退役或更新時便可安排測試並比較結果;高風險 AI Act 系統的部署者亦須監督系統運作。
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
來源:DEV Community · dev.to