Manutenzione agenti AI post-deployment: perché serve un partner

Prima di tutto una disambiguazione necessaria, perché la query è ambigua: qui non si parla di agenti AI che gestiscono la manutenzione predittiva degli impianti, ma del contrario. Si parla della manutenzione agenti AI aziendali, cioè di che cosa succede a un agente dopo il go-live: chi lo controlla, chi lo aggiorna, chi paga quando il modello sottostante viene dismesso.

È la domanda che nessuno fa in fase di valutazione e che tutti si fanno al terzo mese di produzione. Un agente AI non è un software che, una volta collaudato, resta identico a se stesso: dipende da un modello che cambia, da dati che cambiano e da processi aziendali che cambiano. Chi lo tratta come un progetto chiuso scopre in fretta che il valore si erode senza che nessuno abbia toccato una riga di codice.

In questo articolo scoprirai:

• Che cosa significa manutenzione agenti AI aziendali (e cosa non significa)
• Drift: perché un agente che funzionava smette di funzionare
• Prompt, knowledge base e RAG: la manutenzione del contesto
• Hallucination e supervisione: monitorare la qualità in produzione
• Costi token e fine vita dei modelli: le due sorprese di bilancio

Che cosa significa manutenzione agenti AI aziendali (e cosa non significa)

Un agente AI è un sistema che riceve un obiettivo, ragiona su come raggiungerlo e usa strumenti, API, database, gestionali, per agire. Questa autonomia è esattamente ciò che lo rende utile ed è anche ciò che rende la sua manutenzione diversa da quella di un applicativo tradizionale.

Il punto lo formula bene la letteratura di settore: la fase post-deployment è quella che determina se un sistema AI produce valore sostenuto o diventa una liability, e si articola in quattro domini, manutenzione correttiva (difetti ed errori), adattiva (cambi di API, dati, normative), perfettiva (performance e costi) e preventiva (monitoraggio e rilevazione del drift), come sintetizza AI Technology Authority.

Perché la manutenzione di un agente AI non è normale assistenza IT

L’assistenza IT classica interviene quando qualcosa si rompe: un errore, un servizio giù, un ticket. Con un agente AI il guasto più costoso non produce nessun errore. L’agente risponde, risponde in tempo, risponde in modo plausibile, e risponde peggio di sei mesi prima. Nessun log rosso, nessun alert.

Google Cloud lo dice senza giri di parole nella sua guida MLOps: «i modelli possono decadere in più modi rispetto ai sistemi software convenzionali», perché sono sensibili all’evoluzione dei dati e non solo ai bug di codice (Google Cloud Architecture Center). Ne segue che la vera sfida non è mettere in produzione un modello, ma «costruire un sistema integrato e operarlo in modo continuativo in produzione». Tradotto per una PMI: il deliverable non è l’agente, è il presidio.

Drift: perché un agente che funzionava smette di funzionare

Drift è il termine tecnico per lo scostamento tra il mondo su cui il sistema è stato tarato e il mondo in cui opera oggi. Si presenta in due forme, entrambe rilevanti anche per agenti basati su LLM e non solo per modelli predittivi classici.

Il data drift è il cambiamento degli input: gli utenti iniziano a scrivere in modo diverso, arrivano richieste su prodotti che sei mesi prima non esistevano, cambia il mix di lingue o di canali. Il concept drift è più insidioso: la domanda resta identica, ma la risposta corretta è cambiata, nuova policy di reso, nuovo listino, nuovo obbligo normativo. L’agente continua a rispondere con sicurezza la verità dell’anno scorso.

Come si rileva il drift di un agente in produzione

La risposta operativa è un eval set: un insieme di casi di prova con la risposta attesa, che si rilancia periodicamente per confrontare il comportamento attuale con una baseline. Chi opera agenti in produzione consiglia di mantenere un periodo di monitoraggio elevato di almeno una settimana dopo aver portato l’agente al 100% del traffico e di confrontare le metriche di produzione con le baseline di valutazione per identificare lo scostamento tra comportamento atteso e reale (Harness Engineering).

Sul quando reagire, la pratica del model monitoring individua tre famiglie di trigger per il retraining o l’aggiornamento: a intervalli fissi, basati sul degrado di performance, o attivati da variazioni dei dati in ingresso oltre una soglia (Fiddler AI). Per una PMI il trigger realistico è il secondo, ma richiede che qualcuno stia misurando: senza eval set il degrado si scopre dal cliente insoddisfatto, che è il rilevatore più costoso disponibile.

Prompt, knowledge base e RAG: la manutenzione del contesto

La seconda area di manutenzione non riguarda il modello ma ciò che gli diamo in pasto. Un agente aziendale utile è quasi sempre un agente RAG: recupera documenti dalla base di conoscenza aziendale e risponde su quelli. Il che significa che la qualità dell’agente è vincolata alla qualità e all’aggiornamento della knowledge base, non alla potenza del modello.

Qui la manutenzione è concreta e ricorrente: reindicizzare i documenti aggiornati, rimuovere le versioni obsolete (il problema numero uno nelle basi documentali aziendali è la coesistenza di tre versioni della stessa procedura), rigenerare gli embedding, le rappresentazioni numeriche dei testi usate per la ricerca semantica, quando si cambia modello di indicizzazione, verificare che i permessi di accesso siano ancora coerenti dopo una riorganizzazione.

Aggiornamento dei prompt: piccolo intervento, grande rischio

Anche i prompt di sistema, le istruzioni che definiscono ruolo, tono e limiti dell’agente, sono asset da manutenere. Cambia un processo, va cambiata l’istruzione. Il rischio è che una modifica pensata per correggere un comportamento ne rompa altri tre, e che nessuno se ne accorga perché non esiste una suite di regressione. È il motivo per cui il prompt engineering in produzione va versionato e testato come codice, non modificato a mano in un pannello.

Va aggiunta la manutenzione adattiva delle integrazioni: ogni agente che parla con ERP, CRM o gestionale eredita il ciclo di vita di quelle API. Un endpoint che cambia formato è un guasto dell’agente, ed è uno dei punti dove l’integrazione con i sistemi legacy genera più lavoro ricorrente di quanto preventivato.

Hallucination e supervisione: monitorare la qualità in produzione

Le allucinazioni non si eliminano, si contengono e si misurano. La disciplina che il mercato enterprise ha consolidato si chiama osservabilità e ha tre gambe: tracing, valutazione, monitoraggio. Microsoft, nella documentazione di Foundry, definisce per la fase post-produzione quattro pratiche esplicite: valutazione continua della qualità e sicurezza su un campione del traffico reale, valutazione schedulata su dataset di test per rilevare il drift di sistema, red teaming periodico e alert quando gli output non superano le soglie di qualità (Microsoft Learn).

La parola chiave è «campione»: nessuno valuta il 100% delle conversazioni a mano. Si campiona, si misura la groundedness (quanto la risposta è ancorata alle fonti recuperate), si tiene traccia delle chiamate agli strumenti e si guarda dove la traiettoria dell’agente ha divergiato dal comportamento atteso.

Il rischio di autonomia eccessiva va manutenuto nel tempo

C’è poi un rischio che cresce silenziosamente con l’uso: OWASP lo classifica come Excessive Agency e lo scompone in funzionalità eccessive, permessi eccessivi e autonomia eccessiva, raccomandando di limitare le estensioni richiamabili al minimo necessario e usare un controllo human-in-the-loop per approvare le azioni a impatto elevato, oltre al rate limiting come misura di contenimento del danno (OWASP GenAI Security Project).

Il punto di manutenzione è che i permessi si accumulano. Ogni nuovo caso d’uso aggiunge un tool, ogni tool aggiunge una possibilità di azione, e dopo un anno l’agente può fare cose che nessuno ha deciso consapevolmente di autorizzare. La revisione periodica del perimetro di autonomia è una voce di SLA, non un’attività straordinaria.

Costi token e fine vita dei modelli: le due sorprese di bilancio

Le due voci che più spesso mandano fuori budget un progetto AI non riguardano lo sviluppo ma l’esercizio.

Ottimizzazione dei costi token

I token sono le unità in cui si misura e si fattura il testo elaborato dal modello. Il consumo non è stabile: cresce quando l’agente fatica. Come nota Harness Engineering, «un improvviso aumento dei token per task spesso significa che l’agente sta faticando, ritentando o entrando in loop di ragionamento», e la raccomandazione operativa è impostare gli alert sul p95 del consumo, il 95° percentile, e non sulla media, perché è la coda che genera la bolletta. La manutenzione qui è lavoro di ottimizzazione: caching, routing verso modelli più economici per i task semplici, riduzione del contesto inutile. Sono interventi che si ripagano, ma solo se qualcuno li fa. Il tema si lega direttamente a quanto costa davvero implementare un agente AI: il TCO è dominato dall’esercizio, non dal setup, ed è la ragione per cui molti progetti di AI generativa non arrivano al ROI.

Cosa succede quando il modello viene dismesso

Questo non è uno scenario teorico ed è verificabile sulla documentazione dei provider. Anthropic dichiara che ritira regolarmente i modelli più vecchi e garantisce almeno 60 giorni di preavviso prima del ritiro per i modelli rilasciati pubblicamente: Claude Sonnet 4 e Opus 4 sono stati deprecati il 14 aprile 2026 e ritirati il 15 giugno 2026, e «le richieste ai modelli ritirati falliranno» (Anthropic Docs). OpenAI, dal suo lato, indica almeno 6 mesi di preavviso per i modelli in general availability e circa due settimane per i modelli preview, con date di shutdown pubblicate: gpt-4-0613 e gpt-3.5-turbo-0125 sono in calendario per il 23 ottobre 2026 (OpenAI Deprecations).

Significa che ogni agente in produzione ha una scadenza tecnica implicita e che la migrazione a un modello successivo è un progetto pianificabile, con retest dell’eval set, perché un modello nuovo non è automaticamente migliore sul tuo compito. Se non c’è nessuno che monitora quelle pagine di changelog, la scadenza arriva come un’interruzione di servizio. Vale la pena capire come funzionano gli LLM almeno a livello di ciclo di vita: è la parte del rischio che non si può delegare all’ignoranza.

Team interno o partner esterno: il make-or-buy della manutenzione agenti AI aziendali

Messe in fila le aree, drift, contesto, qualità, sicurezza, costi, ciclo di vita dei modelli, la domanda diventa economica: chi presidia? La risposta non è ideologica, dipende dalla soglia di massa critica.

Un presidio interno richiede competenze che raramente stanno in una sola persona: valutazione di sistemi LLM, ingegneria dei dati, osservabilità, sicurezza applicativa, oltre alla conoscenza di dominio. Il ciclo di vita AI, ricorda Data Science PM, non è lineare: «va pensato come un processo iterativo che consegna incrementalmente una soluzione migliore», in cui ogni fase viene rivisitata molte volte (Data Science PM). Un processo iterativo permanente su un solo agente non satura una figura full-time, ma non tollera nemmeno di essere l’ottava priorità di chi gestisce anche rete e backup.

Quando conviene un contratto di servizio

Per una PMI con uno o due agenti in produzione il partner esterno vince su tre fronti misurabili: costo marginale (la strumentazione di osservabilità e le pratiche di eval sono già costruite e ammortizzate su più clienti), tempo di reazione (chi vede dieci agenti riconosce un pattern di degrado prima di chi ne vede uno) e continuità (una competenza contrattualizzata non va in ferie e non si dimette). Il presidio interno torna conveniente quando gli agenti diventano molti, toccano dati particolarmente sensibili o costituiscono il prodotto stesso dell’azienda, una valutazione che si intreccia con la scelta tra agenti custom e soluzioni off-the-shelf.

È esattamente il gap del «oltre al prodotto»: la differenza tra comprare uno strumento e comprare un risultato che resta valido nel tempo. Un tema che abbiamo già affrontato spiegando perché, in ambito enterprise, il servizio conta più del modello e nella scelta tra agente chiavi in mano e self-service. Va aggiunto un fattore non tecnico: senza change management, il feedback degli utenti, la fonte primaria per capire che l’agente sta peggiorando, non arriva mai a chi potrebbe intervenire.

Checklist: cosa chiedere in un SLA per la manutenzione di un agente AI

Questa lista è utilizzabile con qualsiasi fornitore, incluso il vostro attuale. Serve a trasformare «ci occupiamo noi della manutenzione» in obblighi verificabili.

Manutenzione agenti AI: cosa verificare sul piano tecnico

• Eval set e baseline: esiste un insieme di casi di test con risposte attese? Chi lo mantiene? Con che frequenza viene rilanciato e chi riceve il report?
• Metriche e soglie: quali indicatori sono monitorati (accuratezza sui casi di test, groundedness, tasso di escalation, latenza, token per task) e a quale soglia scatta un intervento?
• Frequenza di aggiornamento della knowledge base: chi reindicizza, entro quanto tempo da una modifica documentale, e come si verifica che i contenuti obsoleti siano stati rimossi.
• Gestione del fine vita dei modelli: chi monitora le pagine di deprecation dei provider, chi pianifica la migrazione, chi paga il retest. Da fissare come obbligo, dato il preavviso minimo di 60 giorni dichiarato da alcuni provider.

Manutenzione agenti AI: cosa fissare sul piano contrattuale

• Tempi di risposta differenziati: un errore bloccante e un degrado silenzioso di qualità non possono avere lo stesso SLA. Servono due categorie con tempi distinti.
• Revisione periodica di permessi e autonomia: cadenza della verifica su tool abilitati, privilegi sui sistemi collegati e azioni che richiedono approvazione umana.
• Trasparenza sui costi di esercizio: reporting del consumo token e responsabilità dell’ottimizzazione. Se il fornitore fattura i token a margine, l’incentivo a ottimizzare è disallineato: verificatelo.
• Proprietà e portabilità: prompt, eval set, log e knowledge base restano vostri e sono esportabili in formato utilizzabile alla cessazione del contratto.
• Onboarding e formazione ricorrente: chi affianca gli utenti al go-live e chi li riallinea quando l’agente cambia comportamento.

Se un fornitore risponde a queste nove voci con date, nomi e numeri, state comprando un servizio. Se risponde con rassicurazioni, state comprando un prodotto e la manutenzione resterà, di fatto, un vostro problema.

In Mimír lavoriamo esattamente su questo secondo tempo del progetto: onboarding assistito, presidio continuativo dell’agente e affiancamento del team, perché un agente AI genera valore solo finché qualcuno se ne occupa. Se state valutando un investimento in AI o avete già un agente in produzione senza un presidio chiaro, parliamone in una consulenza: il momento migliore per definire la manutenzione è prima del go-live, il secondo migliore è oggi.

Fonti:

• AI Technology Authority — AI services, support and maintenance
• Google Cloud Architecture Center — MLOps: continuous delivery e automazione
• Google Cloud — MLOps continuous delivery and automation pipelines
• Harness Engineering — Production AI agent deployment: operations guide
• Fiddler AI — How do you maintain a deployed model
• Microsoft Learn — Observability in Azure AI Foundry
• OWASP GenAI Security Project — LLM06: Excessive Agency
• Anthropic — Model deprecations (Claude Platform)
• Anthropic Docs — Model deprecations
• OpenAI Developers — API deprecations
• OpenAI Platform — Deprecations
• Data Science PM — The AI lifecycle
• Michael Brenndoerfer — AI agent maintenance and updates guide
• Cloudflare Learning — How to manage AI agents for businesses