Gestione continua agenti AI: cosa include il contratto col partner

Il momento più pericoloso nella vita di un agente AI aziendale non è il lancio. È il terzo mese, quando tutti hanno smesso di guardarlo. L’agente risponde ancora, i log non segnalano errori, il team ha archiviato il progetto come “fatto”, e intanto la precisione delle risposte sta scendendo, il modello che ci sta sotto ha una data di pensionamento già fissata, e la knowledge base contiene un listino prezzi di aprile.

Il contratto di gestione continua è la parte del lavoro che non compare nei preventivi e che decide se l’investimento produce valore per anni o si spegne lentamente. Questo articolo prova a mettere nero su bianco cosa contiene davvero un contratto di gestione continua con un partner: cosa si monitora, cosa si aggiorna, chi risponde alle tre di notte quando cade un fornitore a monte, e quanto costa, soprattutto, quanto costa non averlo. Se ti serve il quadro generale di cosa sia un agente e cosa sappia fare, parti dalla guida su cosa sono gli agenti AI e come funzionano; qui diamo per scontato che l’agente sia già in produzione.

In questo articolo scoprirai:

• Cosa succede a un agente AI il giorno dopo il go-live
• Aggiornamenti dei modelli: quando il motore dell’agente va in pensione (o migliora troppo)
• Parametri deprecati: quando aggiornare il modello rompe l’agente AI
• Drift dei dati e retraining: quando la conoscenza dell’agente invecchia
• Incidenti: cosa insegna il blackout Cloudflare del 18 novembre 2025
• Guardrail e AI Act: la manutenzione che è anche un obbligo di legge
• Quanto costa la manutenzione di un agente AI

Cosa succede a un agente AI il giorno dopo il go-live

C’è un’assunzione implicita, ereditata dal software tradizionale, che è la radice di quasi tutti i problemi: che un sistema collaudato resti collaudato. Con il codice deterministico è ragionevole. Con un agente costruito su un modello linguistico non lo è, perché almeno quattro componenti su cui l’agente si appoggia cambiano senza che tu faccia nulla: il modello del fornitore, i dati aziendali, le API dei sistemi collegati e il comportamento degli utenti.

Un lavoro accademico pubblicato quest’anno su arXiv, “Your Agents Are Aging Too”, ha provato a misurare questo invecchiamento in modo sistematico su circa 400 esecuzioni, 14 modelli e sessioni lunghe fino a 200 interazioni. Gli autori distinguono quattro meccanismi di degrado: compressione della cronologia che perde informazione, interferenza fra memorie accumulate, revisioni di fatti che generano incoerenze, e il degrado indotto dalle operazioni di manutenzione stesse. Ma il risultato più scomodo per chi gestisce un agente in azienda è un altro: i test comportamentali possono restare puliti mentre la precisione fattuale si erode. Tradotto: la dashboard è verde e l’agente sta già sbagliando.

Questo è il motivo per cui il monitoraggio “l’agente risponde / non risponde” è insufficiente. Serve una valutazione periodica sulla qualità delle risposte, non solo sulla disponibilità del servizio, ed è esattamente la differenza fra un contratto di hosting e un contratto di gestione. La distinzione fra i due la abbiamo approfondita in manutenzione agenti AI post-deployment: perché serve un partner.

Aggiornamenti dei modelli: quando il motore dell’agente va in pensione (o migliora troppo)

Questa è la voce di manutenzione più sottovalutata e la più facile da documentare con numeri veri, perché i fornitori pubblicano le date.

Le date di ritiro dei modelli che nessuno mette in calendario

La pagina ufficiale delle model deprecations di Anthropic è un documento che ogni responsabile IT con un agente in produzione dovrebbe avere fra i preferiti. Anthropic garantisce almeno 60 giorni di preavviso prima del ritiro di un modello pubblico, e dopo la data di ritiro le richieste a quel modello semplicemente falliscono. Non degradano: falliscono.

I fatti degli ultimi dodici mesi, tutti verificabili sulla tabella ufficiale delle deprecation, danno la misura del ritmo. Claude Sonnet 3.7 è stato ritirato il 19 febbraio 2026, Claude Opus 3 il 5 gennaio 2026, Claude Haiku 3 il 20 aprile 2026, Sonnet 4 e Opus 4 il 15 giugno 2026, e Claude Opus 4.1, deprecato il 5 giugno, è stato ritirato il 5 agosto 2026, tre settimane fa. Nel frattempo la linea attiva è arrivata a Claude Opus 5 e Sonnet 5. Chi ha scritto l’identificativo del modello in una variabile d’ambiente sei mesi fa e non ha più riaperto quel file, prima o poi trova l’agente fermo un lunedì mattina.

Parametri deprecati: quando aggiornare il modello rompe l’agente AI

C’è un dettaglio ancora più insidioso nella stessa pagina di Anthropic, che riguarda i parametri e non i modelli: temperature, top_p e top_k sono deprecati su Claude Opus 4.7 e successivi e restituiscono un errore 400 se impostati a un valore non predefinito. Significa che il semplice passaggio a un modello più recente rompe codice perfettamente funzionante, senza che nessuno abbia toccato la logica dell’agente. È il tipo di lavoro che qualcuno deve fare, e la domanda è solo se quel qualcuno è nel tuo team o nel contratto. Sui costi e sulle scelte di piattaforma abbiamo scritto in API di Claude: costi 2026 e quando conviene rispetto all’abbonamento.

Perché l’agente si rompe anche quando il modello migliora

Il caso contrario è meno ovvio e più frequente di quanto si creda. Un’analisi di MindStudio sulla manutenzione dell’harness lo formula così: gli agenti falliscono non perché il modello peggiora, ma perché migliora. L'”harness” è tutta l’impalcatura intorno al modello, system prompt, parser dell’output, regole di routing, gestione della memoria, handler dei tool, fallback, e un modello nuovo la disallinea in modi specifici: cambia il formato dell’output e rompe i parser, segue le istruzioni meglio e scavalca la logica compensativa scritta per i suoi difetti precedenti, espone il ragionamento in modo più esplicito e confonde gli estrattori che cercano la risposta finale.

La contromisura è nota e costa poco se è routine, molto se è emergenza: un golden set di input canonici con output attesi, da rieseguire come test di regressione a ogni cambio di modello, più un confronto affiancato fra versioni sugli stessi input. Un aggiornamento di modello va trattato come un aggiornamento di dipendenza, non come un’impostazione da cambiare in produzione il venerdì pomeriggio.

Drift dei dati e retraining: quando la conoscenza dell’agente invecchia

Il modello è solo metà del problema. L’altra metà è ciò che l’agente sa. Un agente che risponde ai clienti su prodotti, prezzi, condizioni contrattuali o procedure interne è accurato quanto la base documentale che interroga, e quella base invecchia al ritmo dell’azienda, non al ritmo dei fornitori di AI.

Nella pratica il degrado arriva da tre direzioni. La prima è il contenuto obsoleto: documenti superati che restano indicizzati accanto a quelli nuovi, con l’agente che pesca la versione sbagliata perché è semanticamente altrettanto pertinente. La seconda è il concept drift vero e proprio: cambiano le domande che arrivano, perché è cambiato il catalogo o è partita una campagna, e la copertura documentale che andava bene a gennaio lascia scoperto il 20% delle richieste di settembre. La terza è più sottile ed è il degrado dei prompt: modifiche incrementali fatte da persone diverse per risolvere casi singoli, che si sommano fino a peggiorare il comportamento medio.

Manutenzione della knowledge base e architettura di recupero

Per questo un contratto serio distingue fra aggiornamento della knowledge base, operazione di igiene, con cadenza fissa, e revisione dell’architettura di recupero, che è lavoro ingegneristico: rivedere il chunking, le soglie di similarità, i filtri sui metadati, la strategia di re-ranking. Se il termine “recupero” non ti dice nulla, la meccanica è spiegata nella guida su cos’è il RAG e perché è fondamentale per l’AI. Microsoft, nella sua documentazione sul ciclo di vita degli agenti, mette questa fase, quella che chiama operational steady state, allo stesso livello delle altre quattro: monitorare, valutare e correggere in continuo “man mano che i requisiti di business e le tecnologie sottostanti evolvono”. Non è un’appendice del progetto: è una delle cinque fasi.

Incidenti: cosa insegna il blackout Cloudflare del 18 novembre 2025

Il 18 novembre 2025 buona parte di internet ha smesso di funzionare, e con lei una quantità di assistenti AI raggiungibili solo attraverso quell’infrastruttura. Il post-mortem pubblicato da Cloudflare ricostruisce la catena con una precisione che vale la lettura: alle 11:05 UTC viene applicata una modifica ai permessi di un database, una query ClickHouse inizia a restituire metadati di colonna duplicati, il file di configurazione del modulo Bot Management raddoppia di dimensione, supera il limite di 200 feature previsto in memoria (l’uso normale è circa 60) e manda in panic il proxy FL2. Errori HTTP 5xx su tutta la rete. Impatto dalle 11:20 alle 17:06 UTC: cinque ore e quarantasei minuti, il peggior guasto Cloudflare dal 2019, e nessun attacco, una modifica di permessi.

La lezione non è “evitate i fornitori cloud”, che è impossibile. È che il tuo agente eredita la disponibilità di ogni componente della catena: modello, gateway, CDN, database vettoriale, CRM. Un contratto di gestione continua deve dire cosa succede in quelle sei ore: esiste un fallback su un modello di un secondo fornitore? L’agente degrada in modo controllato, messaggio onesto all’utente e coda di richieste, o restituisce errori grezzi? Chi apre l’incidente, chi avvisa il cliente, con che tempi?

Rollback, canary e degrado controllato dell’agente AI

Sul lato operativo, le pratiche mature sono poco spettacolari e molto efficaci. La guida n8n sul deployment in produzione insiste su tre cose: un rollback documentato che si completi in pochi minuti e che sia stato provato almeno una volta in staging prima di servire davvero, rilasci canary con traffico instradato per gradi (5% → 25% → 50% → 100%), e sorveglianza stretta del tasso di errore rispetto alla baseline della versione precedente nelle 2-4 ore successive a ogni rilascio. Tutto questo va scritto nei livelli di servizio: quali garanzie chiedere, e come formularle, lo abbiamo dettagliato in SLA agenti AI: quali garanzie chiedere al partner prima di firmare.

Guardrail e AI Act: la manutenzione che è anche un obbligo di legge

C’è una parte della gestione continua che in Europa non è una scelta di qualità ma un adempimento. L’articolo 72 dell’AI Act impone ai fornitori di sistemi di AI ad alto rischio di istituire e documentare un sistema di sorveglianza post-commercializzazione, proporzionato alla natura e ai rischi della tecnologia. Non è un adempimento con una scadenza: è un obbligo che accompagna il sistema per tutta la sua vita operativa, e richiede di raccogliere, documentare e analizzare i dati di performance per valutare la conformità continua ai requisiti del Capo III. Il piano di monitoraggio va integrato nella documentazione tecnica.

Tradotto in pratica, significa che i log delle interazioni, le metriche di qualità, i registri degli incidenti e le revisioni dei guardrail non sono materiale interno da tenere finché serve: sono documentazione da produrre, conservare e mantenere aggiornata. E i guardrail stessi, filtri sui contenuti, limiti sulle azioni che l’agente può compiere sui sistemi aziendali, soglie di escalation verso un operatore umano, vanno rivisti quando cambia il modello, perché come si è visto un modello nuovo ha pattern di rifiuto diversi da quello che ha sostituito. Su chi decide cosa e con quali ruoli abbiamo scritto in governance agenti AI: policy, ruoli e AI Act, mentre il taglio operativo per l’azienda è in AI Act e agenti AI in azienda: compliance con un partner.

Quanto costa la manutenzione di un agente AI

Sui numeri conviene essere precisi su cosa è misurato e cosa è stimato. Il riferimento più citato nel mercato italiano colloca il costo annuo di manutenzione fra il 10% e il 20% del costo di sviluppo iniziale: è la forchetta pubblicata da Yellow Tech nella sua guida sullo sviluppo di agenti AI, articolata su tre livelli, base (monitoraggio, alerting, aggiornamenti di sicurezza), standard (tuning mensile dei prompt, aggiornamento della knowledge base, supporto con SLA) e premium (team dedicato ed evoluzione continua). Sul mercato anglosassone la forchetta riportata è leggermente più alta, 15-25% annuo, attribuita a Gartner da un fornitore del settore: è una citazione di seconda mano, non l’abbiamo verificata alla fonte primaria, e va presa come ordine di grandezza. Lo stesso documento propone una ripartizione della spesa che è utile come griglia mentale: 30% correzione del drift, 20% tuning dei prompt e test di regressione, 20% aggiornamenti di API e infrastruttura, 15% monitoraggio, 15% patching e compliance.

Il modello “compro le API e mi arrangio”: dove si rompe

L’alternativa esiste ed è legittima: si comprano le API, si costruisce internamente, si gestisce con le proprie persone. Funziona quando in azienda c’è già un team che fa MLOps, che ha una pratica di test di regressione, che presidia il calendario delle deprecation e che può reggere un incidente fuori orario. Nelle PMI italiane questa condizione è rara, e il costo non sparisce: si sposta sulle stesse due o tre persone che hanno già altro da fare, sotto forma di lavoro non pianificato. Su cosa chiedere e cosa aspettarsi quando quella competenza si compra fuori, il dettaglio è in consulenza agenti AI per PMI: cosa aspettarsi da un partner.

Il costo di non fare manutenzione: il 40% dei progetti agentici cancellati

Il conto vero, però, è quello che non si vede a bilancio. Gartner prevede che oltre il 40% dei progetti di AI agentica sarà cancellato entro la fine del 2027, previsione pubblicata il 25 giugno 2025 su una base di oltre 3.400 organizzazioni, e le cause indicate non sono tecnologiche: costi in crescita, valore di business poco chiaro, controlli di rischio inadeguati, progetti avviati senza una strategia e senza governance. La stessa ricerca segnala il fenomeno dell’agent washing: fra le migliaia di fornitori che dichiarano capacità agentiche, secondo Gartner solo circa 130 le hanno davvero (sintesi su MarTech). Un agente abbandonato non costa il 15% all’anno: costa il 100% dell’investimento iniziale, più il tempo perso, più la fiducia interna bruciata, che è la voce più cara da ricostruire. È lo stesso meccanismo che descriviamo in se l’AI generativa non genera ROI, il problema non è la tecnologia. Per le formule di ingaggio e le fasce di prezzo dell’affiancamento continuativo, il dettaglio è in quanto costa l’affiancamento su un agente AI.

Cosa deve contenere il contratto di gestione continua con il partner

Un contratto di manutenzione che dice “assistenza e aggiornamenti” non è un contratto: è una speranza. Le voci che rendono verificabile l’impegno sono poche e concrete, e vale la pena chiederle esplicitamente prima di firmare.

Monitoraggio della qualità, non solo dell’uptime: quali metriche vengono misurate (tasso di completamento del task, tasso di escalation a operatore umano, errori di parsing, deviazione dalla baseline), con quale frequenza vengono riviste e in che formato arriva il report. Gestione del ciclo di vita del modello: chi presidia le date di deprecation dei fornitori, con quanto anticipo viene pianificata la migrazione, chi esegue i test di regressione sul golden set prima del passaggio e chi risponde se l’output cambia forma. Aggiornamento della base di conoscenza: cadenza, responsabilità di chi fornisce i contenuti aggiornati, tempi di propagazione. Gestione degli incidenti: tempi di presa in carico distinti per severità, procedura di rollback provata, comportamento in degrado quando cade un fornitore a monte, canale di reperibilità. Revisione dei guardrail e documentazione di conformità: chi mantiene i registri richiesti dall’articolo 72 e chi li aggiorna quando cambia il modello.

Continuità con le fasi precedenti: onboarding, handover, formazione

La gestione continua non nasce dal nulla il giorno del go-live: è la prosecuzione di quello che è stato costruito prima. Se l’onboarding dei primi 30 giorni è stato fatto bene, esistono già la baseline delle metriche e i casi di test che serviranno per anni. Se l’handover al team IT ha prodotto documentazione vera, il partner e il cliente parlano la stessa lingua durante un incidente.

E se le persone che usano l’agente sanno riconoscere una risposta sbagliata e segnalarla, il monitoraggio ha un sensore che nessuna dashboard sostituisce: per questo la formazione del team è parte della manutenzione, non un extra. Nella scelta del fornitore, i criteri per valutare chi regge davvero questa fase sono raccolti in come scegliere il partner giusto per gli agenti AI.

Come funziona la gestione continua in MIMIR

È esattamente il modo in cui lavoriamo in MIMIR: non vendiamo un agente e ci salutiamo al go-live, ma un servizio che accompagna il sistema nel tempo, assessment iniziale, onboarding assistito, e poi la gestione continua che tiene insieme monitoraggio, aggiornamenti dei modelli, revisione dei guardrail e risposta agli incidenti. Perché un agente AI non è un prodotto che si consegna: è un sistema che vive, e i sistemi che vivono hanno bisogno di qualcuno che li guardi.

Se in azienda avete un agente già in produzione e vi state accorgendo che nessuno ne sta davvero presidiando il “dopo”, o se state valutando un progetto e volete capire in anticipo cosa comporterà mantenerlo, potete parlarne con noi su mimir.bot. Una conversazione per capire dove siete e cosa serve non costa nulla, e spesso chiarisce più di un preventivo.

Fonti:

• “Your Agents Are Aging Too” — misurazione dell’invecchiamento degli agenti (arXiv)
• Model deprecations e parametri deprecati (documentazione Anthropic)
• MindStudio — manutenzione dell’harness quando i modelli migliorano
• Microsoft Learn — ciclo di vita del deployment degli agenti
• Post-mortem Cloudflare del guasto del 18 novembre 2025
• n8n — best practice per il deployment di agenti AI in produzione
• AI Act, articolo 72 — sorveglianza post-commercializzazione
• TrainMyAgent — ripartizione dei costi di manutenzione post-deploy
• Gartner — comunicato del 25 giugno 2025 sui progetti agentici cancellati entro il 2027
• MarTech — agent washing e ruolo delle persone nei progetti agentici