Aggiornare un assistente AI dopo il lancio senza perdere affidabilità

Aggiornare un assistente AI dopo il lancio richiede lo stesso metodo di qualsiasi sistema in produzione. Si raccolgono le segnalazioni in un unico registro. Poi si modificano istruzioni, fonti o regole di instradamento, una cosa alla volta. Infine si verifica ogni nuova versione su un set di prova prima di pubblicarla. Senza questo ciclo, l'affidabilità misurata al go-live cala in pochi mesi.

La manutenzione di un assistente AI è l'insieme di queste attività ripetute nel tempo, dopo il go-live, cioè dopo il giorno in cui l'assistente inizia a servire utenti reali. La manutenzione non coincide con la correzione occasionale di una risposta sbagliata. È un processo con un responsabile, un calendario e un criterio chiaro per decidere quando una versione può uscire.

Il motivo è semplice. Il modello non conosce i Suoi listini, le Sue procedure o i Suoi reparti: li legge dalle fonti e dagli strumenti che gli mette a disposizione. Secondo la panoramica ufficiale dei modelli Claude, i quattro modelli attuali hanno un limite affidabile di conoscenza fissato a giugno 2026. Tutto ciò che cambia nella Sua azienda arriva all'assistente solo attraverso ciò che Lei aggiorna.

Questa guida è pensata per chi ha già un assistente Claude collegato a Zoho e deve organizzarne la manutenzione. Spiega quali parti invecchiano, come gestire le modifiche, come verificarle e cosa controllare quando cambia il modello.

Un assistente Claude in produzione invecchia in tre punti distinti, e ciascuno richiede un controllo diverso. Separarli fin dall'inizio rende la manutenzione molto più semplice, perché ogni segnalazione si può attribuire a una delle tre parti.

Le fonti di conoscenza

Le fonti di conoscenza sono i documenti e i dati che l'assistente consulta per rispondere: procedure, schede prodotto, articoli della base di conoscenza, record di Zoho CRM. Invecchiano ogni volta che l'azienda cambia un prezzo, un orario o una procedura e nessuno aggiorna il documento.

Le istruzioni

Le istruzioni, spesso chiamate prompt di sistema, sono il testo che dice all'assistente chi è, come deve rispondere e cosa non deve fare. Invecchiano quando cambiano il tono richiesto, le eccezioni ammesse o i limiti di ciò che l'assistente può promettere.

Le regole di instradamento

Le regole di instradamento stabiliscono a quale reparto, coda o persona va una richiesta. In un assistente che apre ticket in Zoho Desk, sono le regole che scelgono dipartimento, categoria e priorità. Invecchiano quando nasce un nuovo servizio, si riorganizza un team o si rinomina una categoria.

Le tre parti dipendono da dove l'assistente legge e scrive nei Suoi sistemi. Se questo punto non è ancora chiaro, la guida su dove un assistente AI legge e scrive negli strumenti aziendali è un buon punto di partenza.

Ogni modifica a un assistente AI deve partire da una segnalazione scritta in un registro unico. Le segnalazioni sparse in chat, email e conversazioni di corridoio si perdono. Inoltre non permettono di capire se un errore è isolato o ricorrente.

Il registro può essere una coda dedicata in Zoho Desk, un modulo o un semplice elenco condiviso. Lo strumento conta meno della disciplina. Ogni voce dovrebbe contenere almeno questi elementi:

• la domanda o la richiesta esatta che l'utente ha inviato;
• la risposta o l'azione dell'assistente, copiata senza modifiche;
• la risposta o l'azione corretta, scritta da chi conosce il processo;
• la parte coinvolta: fonte, istruzioni o instradamento;
• la data e chi ha segnalato il problema.

Il registro serve a due scopi. Il primo è decidere cosa correggere, partendo dagli errori più frequenti o più costosi. Il secondo è alimentare il set di prova: ogni segnalazione risolta diventa un caso da ricontrollare a ogni rilascio successivo.

Conviene fissare un ritmo di revisione, per esempio una riunione breve a cadenza regolare tra chi gestisce l'assistente e il responsabile del processo. In quella sede si classificano le segnalazioni e si decide quali modifiche entrano nella prossima versione. Una segnalazione senza decisione resta aperta, visibile a tutti.

Una modifica alla volta è la regola che permette di sapere quale cambiamento ha prodotto quale effetto. Se nella stessa versione si riscrivono le istruzioni, si aggiorna una fonte e si cambia una regola di instradamento, un peggioramento non è più attribuibile a nessuna delle tre.

Lo sviluppo software tradizionale ha risolto questo problema da tempo. La documentazione Microsoft su l'aggiornamento dei progetti .NET raccomanda di eseguire il backup del codice prima di iniziare. Indica anche di aggiornare i progetti nell'ordine delle dipendenze. Lo strumento che Microsoft consiglia oggi esegue il commit di ogni modifica, così da poterla convalidare o annullare con un rollback.

Gli stessi tre principi valgono per un assistente AI:

1. Backup: conservi una copia datata delle istruzioni e delle fonti in uso, prima di toccarle.
2. Ordine delle dipendenze: aggiorni prima le fonti, poi le istruzioni che le citano, infine le regole di instradamento che usano entrambe.
3. Una modifica per versione: ogni versione ha un numero, una data e una riga che spiega cosa è cambiato e perché.

Il rollback è il ritorno immediato alla versione precedente quando quella nuova si comporta peggio. Funziona solo se la versione precedente è stata salvata intera. Questo vale per le istruzioni, per le fonti e per l'identificativo del modello in uso.

Un set di prova è un elenco fisso di richieste reali, ciascuna con la risposta o l'azione attesa, su cui si fa girare ogni nuova versione dell'assistente prima di pubblicarla. La documentazione di Anthropic chiama queste verifiche evals. Le indica come criterio per decidere quando passare a un modello più potente.

Il set nasce al lancio e cresce con il registro delle segnalazioni. Deve contenere tre tipi di casi:

• le richieste più comuni, che l'assistente deve continuare a gestire bene;
• i casi limite, come richieste ambigue, incomplete o fuori ambito;
• gli errori già segnalati e corretti, perché non tornino.

Il confronto si fa tra versione attuale e versione candidata, sugli stessi casi. La candidata può uscire solo se migliora i casi per cui è stata creata e non peggiora gli altri. Quando organizziamo la manutenzione in Svennis non pubblichiamo una modifica che non abbia superato l'intero set usato al lancio. L'errore che vediamo più spesso è correggere un caso e romperne un altro senza accorgersene.

Per scegliere quali indicatori seguire dopo il rilascio, come tasso di risoluzione o instradamenti corretti, la guida su le metriche che contano per misurare un assistente AI offre un elenco ragionato. Il set di prova dice se una versione può uscire. Le metriche dicono se, una volta uscita, regge con gli utenti reali.

Il modello Claude sotto l'assistente cambia nel tempo, e ogni cambio va trattato come una versione da verificare sull'intero set di prova. Anthropic pubblica nuovi modelli con frequenza. Secondo il newsroom di Anthropic, a settembre 2026 Claude Opus 5.5 offre prestazioni al livello di Claude Fable 5.1 per la maggior parte dei lavori. Costa inoltre il 40% in meno di Claude Opus 5. Claude Sonnet 5.5 è più veloce del 30% rispetto al Sonnet precedente e costa fino al 30% in meno.

La panoramica dei modelli indica per ciascuno l'uso consigliato, il prezzo e la data prima della quale non verrà ritirato:

Modello	Uso indicato da Anthropic	Prezzo per milione di token (input / output)	Ritiro non prima del
Claude Fable 5.1	Ragionamento impegnativo e lavoro agentico di lunga durata	10 / 50 USD	1 settembre 2027
Claude Opus 5.5	Punto di partenza per la maggior parte dei carichi di lavoro	4 / 20 USD	22 settembre 2027
Claude Sonnet 5.5	Più veloce ed economico del Sonnet precedente	2 / 10 USD	28 settembre 2027
Claude Haiku 5.5	Classificazione, estrazione e instradamento ad alto volume	da 0,10 / da 0,50 USD	7 ottobre 2027

Prima di cambiare modello conviene interrogare la Models API, l'interfaccia che descrive i modelli disponibili. Per ogni modello restituisce max_input_tokens, max_tokens e un oggetto capabilities. Le capacità possono differire anche dentro la stessa famiglia. Per Claude Haiku 4.5, per esempio, server_tools.code_execution.supported risulta vero mentre code_execution.supported risulta falso.

Un esempio concreto mostra il metodo applicato dall'inizio alla fine. Immagini un assistente Claude che riceve le richieste interne e apre ticket in Zoho Desk. Per lo smistamento usa Claude Haiku 5.5, il modello che Anthropic indica per classificazione e instradamento.

L'azienda introduce un nuovo servizio con un reparto dedicato in Zoho Desk. Nelle settimane successive gli operatori segnalano ticket finiti nel reparto sbagliato. Il metodo procede in sei passi:

1. Registro: ogni ticket mal instradato entra nel registro con richiesta originale, reparto scelto e reparto corretto.
2. Diagnosi: l'errore riguarda l'instradamento, perché le regole non prevedono il nuovo reparto.
3. Fonte: si aggiunge alla base di conoscenza una descrizione del nuovo servizio, con esempi di richieste tipiche.
4. Regola: in una versione successiva si aggiunge il nuovo reparto alle regole di instradamento, senza toccare le istruzioni generali.
5. Prova: i ticket segnalati entrano nel set di prova. La versione candidata gira su tutto il set, non solo sui casi nuovi.
6. Rilascio: se nessun reparto esistente peggiora, la versione esce e la precedente resta salvata per il rollback.

Supponga ora che la nuova versione aggiunga la ricerca web, per controllare informazioni pubbliche su un fornitore. La documentazione di Anthropic avverte che le impostazioni dell'organizzazione possono far fallire una richiesta anche quando lo strumento è supportato. Un amministratore, per esempio, può disattivare la ricerca web. Questo controllo va fatto prima del rilascio, non dopo le prime richieste fallite.

Una tabella di controllo fissa trasforma la verifica in una routine che chiunque nel team può eseguire. Ogni riga va spuntata prima che una versione esca. Se una riga resta aperta, la versione non esce.

Controllo	Domanda da porsi	Chi lo esegue
Origine della modifica	La modifica nasce da una segnalazione registrata?	Chi gestisce l'assistente
Ampiezza della modifica	La versione cambia una sola cosa: fonte, istruzioni, instradamento o modello?	Chi gestisce l'assistente
Copia di sicurezza	La versione in uso è salvata intera, compreso l'identificativo del modello?	Chi gestisce l'assistente
Set di prova	La candidata ha superato tutti i casi, vecchi e nuovi?	Responsabile del processo
Peggioramenti	Qualche caso che prima funzionava ora fallisce?	Responsabile del processo
Capacità del modello	La Models API conferma le capacità e i limiti di token che la versione usa?	Chi gestisce l'assistente
Impostazioni dell'organizzazione	Gli strumenti richiesti, come la ricerca web, sono abilitati?	Amministratore della piattaforma
Nota di rilascio	Gli utenti sanno cosa cambia e a chi segnalare un problema?	Responsabile del processo

La colonna "Chi lo esegue" conta quanto le domande. Il responsabile del processo conosce le risposte corrette e giudica il set di prova. Chi gestisce l'assistente conosce la parte tecnica. Separare i due ruoli evita che chi ha scritto la modifica sia anche l'unico a giudicarla.

Per un'azienda italiana, la manutenzione di un assistente AI deve tenere conto anche di cambiamenti che arrivano da fuori: norme europee, politiche dei fornitori e supporto della lingua. Nessuno di questi cambiamenti dipende da Lei, ma ciascuno può modificare il comportamento dell'assistente.

Il caso di Apple lo mostra bene. Secondo Libero Tecnologia, Siri AI non è disponibile da subito in Europa per questioni legate al Digital Markets Act. Per il momento non si può usare su iPhone, iPad e Apple Watch europei. Al lancio, inoltre, le funzioni principali sono limitate all'inglese, con l'italiano previsto per ottobre. In Europa, le funzioni dei fornitori possono arrivare più tardi e in lingue diverse.

Ne derivano tre abitudini pratiche:

• scrivere il set di prova in italiano, con le formule che i Suoi utenti usano davvero;
• rileggere le politiche d'uso del fornitore quando cambiano, come l'aggiornamento 2026 della Usage Policy pubblicato da Anthropic l'8 ottobre 2026;
• ripetere le verifiche normative quando una modifica tocca dati personali o decisioni sulle persone.

Per le verifiche su dati personali, la guida su GDPR e legge 132/2025 per un assistente AI elenca i controlli da fare. Per il quadro europeo è disponibile il testo dell'AI Act annotato in italiano.

Il primo passo concreto è nominare un responsabile della manutenzione e aprire il registro delle segnalazioni, anche prima di qualsiasi modifica. Senza questi due elementi, il resto del metodo non ha un punto di partenza.

Nelle settimane successive, l'ordine consigliato è questo:

1. salvare una copia datata delle istruzioni, delle fonti e dell'identificativo del modello in uso;
2. costruire il set di prova partendo dalle richieste più comuni e dalle segnalazioni già raccolte;
3. adottare la tabella di controllo di questa guida e fissare la cadenza delle revisioni;
4. annotare le date di ritiro del modello in uso e pianificare il passaggio con largo anticipo;
5. scegliere due o tre metriche da seguire dopo ogni rilascio.

Resta da decidere chi svolgerà questo lavoro nel tempo: il team interno, un fornitore o un partner. La guida su come scegliere tra AI interna, acquistata o con un partner confronta le tre strade. Il criterio principale è la continuità della manutenzione, non solo il progetto iniziale.

Se vuole capire da dove partire nella Sua azienda, la valutazione di prontezza all'AI aiuta a individuare i processi, i dati e i ruoli da sistemare prima di aggiornare o estendere l'assistente.