Assistenza agenti AI per aziende: cosa include e cosa l’SLA non copre

Chi cerca “assistenza agenti AI” per le aziende di solito sta già oltre la fase della curiosità: ha un agente in produzione, o sta per firmare, e vuole capire cosa può pretendere dal fornitore il giorno dopo il go-live. Va chiarita subito un’ambiguità che confonde anche Google: qui non si parla di agenti AI che fanno assistenza clienti, ma dell’assistenza sull’agente, chi lo tiene in salute, chi risponde quando sbaglia, con quali tempi. È una distinzione che pesa, perché il modello di supporto ereditato dal software tradizionale, apri un ticket quando si rompe, su un agente non funziona male: non funziona affatto, e la ragione è strutturale.

In questo articolo scoprirai:

• Un agente AI non si rompe: peggiora senza avvisare
• Cosa misura l'SLA del tuo fornitore di modello, e cosa non misura
• Monitoraggio proattivo: cosa si guarda per accorgersi in tempo
• Canale diretto e referente unico: perché il ticket anonimo non basta
• Aggiornamenti di configurazione e cambi di modello: il calendario che nessuno vi manda
• Chi risponde se l'agente sbaglia con un cliente
• Assistenza agenti AI per le aziende: come si riconosce un servizio da una licenza

Un agente AI non si rompe: peggiora senza avvisare

Il ticket è un’invenzione del software deterministico. Un gestionale che va in errore restituisce un codice, blocca una schermata, riempie un log: il guasto è un evento discreto, visibile, datato. Qualcuno se ne accorge, apre la segnalazione, il fornitore interviene. Il modello reattivo regge perché il software classico ha la cortesia di dichiarare quando è rotto.

Un agente basato su modelli linguistici non offre questa cortesia. Risponde sempre. Risponde in italiano corretto, con tono sicuro, in duecento millisecondi. Il fatto che la risposta sia diventata sbagliata, perché il catalogo prodotti è cambiato, perché una policy interna è stata aggiornata, perché il modello sotto è stato sostituito con uno che ragiona diversamente, non produce nessun codice di errore. Produce un cliente insoddisfatto che non apre un ticket: cambia fornitore. Il degrado è silenzioso, distribuito su migliaia di conversazioni, e diventa visibile solo quando è già costato qualcosa.

Perché i progetti di AI agentica si fermano dopo il deployment

È il motivo per cui i progetti agentici muoiono dopo il proof of concept più che durante. Gartner, in un comunicato del 25 giugno 2025, prevede che oltre il 40% dei progetti di AI agentica verrà cancellato entro la fine del 2027, e le cause che indica non sono tecnologiche: costi che sfuggono di mano, valore di business non dimostrato, controlli di rischio inadeguati. È una previsione d’analista, non una misura, va letta per quello che è, ma le tre cause hanno un tratto comune: sono tutte cose che si manifestano dopo il deployment, nella fase che il contratto di licenza tipicamente non presidia. Abbiamo raccontato altrove le quattro cause per cui i POC si bloccano; qui il punto è più stretto: se il fallimento arriva dopo l’avvio, il presidio deve stare dopo l’avvio, ed è esattamente la parte che la licenza non include.

Da qui discende tutto il resto. Un’assistenza progettata per un sistema che degrada in silenzio non può essere in attesa di una segnalazione: deve andare a cercare il degrado. E per cercarlo servono metriche, cadenze e un responsabile con un nome, è la ragione per cui, su un agente in produzione, il servizio conta più del modello.

Cosa misura l’SLA del tuo fornitore di modello, e cosa non misura

Prima di chiedere garanzie a un partner, conviene sapere quali garanzie non esistono a monte. Gli SLA dei grandi fornitori di inferenza sono pubblici e vale la pena leggerli letteralmente. L’SLA di Amazon Bedrock definisce «Error» come «qualsiasi richiesta che restituisce un codice di errore 500», e calcola la disponibilità come percentuale di richieste che non falliscono con quegli errori. L’SLA di Vertex AI è costruito sullo stesso principio: il downtime è «un tasso di errore superiore al 5%», dove l’error rate conta gli HTTP 500 e 503, con impegni che vanno dal 99,9% per training e batch prediction al 99,5% per la online prediction su modelli custom.

La conseguenza è netta e va detta senza giri di parole: questi SLA garantiscono che l’API risponda, non che risponda bene. Un agente che restituisce con puntualità esemplare, in HTTP 200, una risposta clamorosamente sbagliata a un cliente è al 100% di uptime secondo qualunque contratto cloud in circolazione. Il rimedio, poi, è simmetrico alla misura: crediti di servizio del 10-25-50% sulla fattura mensile per Vertex, con un tetto al 50%, e, dettaglio che sfugge a molti, l’obbligo di reclamarli entro 30 giorni, pena la decadenza («il cliente decade dal diritto a ricevere un credito economico»). Su Bedrock la finestra è la fine del secondo ciclo di fatturazione. Nessuno vi manda il credito: va chiesto, e qualcuno in azienda deve saperlo.

C’è di più, e va nella stessa direzione. Anche la garanzia di capacità, dove esisteva, si è ristretta: la documentazione Anthropic sui service tier apre con l’avviso che «gli impegni di capacità del tier Priority non sono più disponibili per l’acquisto», riservandolo a chi ha già un impegno in corso; il tier standard resta a «best-effort availability», e il Priority, quando c’era, puntava al 99,5% di uptime. Tradotto: la garanzia più forte che si potesse comprare sul livello di servizio è stata tolta dal listino.

Quali SLA si possono pretendere su un agente AI aziendale

Se l’availability non basta, cosa si mette in un accordo? La ricerca ci è arrivata prima del mercato. Il paper AgentSLA: Towards a Service Level Agreement for AI Agents di Gwendal Jouneaux e Jordi Cabot (Luxembourg Institute of Science and Technology, 4 novembre 2025) propone di estendere lo standard ISO/IEC 25010 sulla qualità del software con dimensioni che gli agenti richiedono e che lo standard non prevedeva: autonomia (quanta interazione umana serve per chiudere un compito), interoperabilità verso protocolli come MCP, comprensibilità, proprietà dell’output come consistenza tra risposte allo stesso prompt.

Due elementi di quel lavoro sono direttamente utilizzabili in una trattativa. Il primo è la formalizzazione di obiettivi misurabili su metriche derivate: l’esempio del paper è un SLO sul Time-To-First-Token medio «less than one second» valutato su dieci messaggi, non su una singola chiamata fortunata. Il secondo, più importante, è la QoSDriftMetric: una metrica che misura l’evoluzione di un’altra metrica nel tempo. È esattamente lo strumento che serve al problema del paragrafo precedente, non «l’agente è disponibile», ma «l’accuratezza dell’agente questo mese è peggiorata rispetto al mese scorso». Il paper introduce anche parametri di incertezza espliciti, riconoscendo il comportamento non deterministico dei modelli: una soglia su un LLM è statistica, e chi la scrive come se fosse binaria sta scrivendo una promessa che non potrà mantenere.

Monitoraggio proattivo: cosa si guarda per accorgersi in tempo

Il monitoraggio proattivo è la voce che distingue di più un’assistenza dedicata da un abbonamento con casella di posta. Non è un dashboard di uptime: è un insieme di osservazioni che qualcuno guarda con una cadenza fissata, cercando peggioramenti invece di attendere guasti.

Le famiglie di indicatori sono tre, e conviene tenerle distinte perché si guastano in modi diversi. La prima è tecnica e la coprono già gli SLA di piattaforma: latenza, tasso di errore, saturazione dei rate limit. La seconda è di qualità della risposta: quota di conversazioni che l’agente chiude da sé, quota che passa a un umano, e soprattutto le risposte in cui l’agente non ha detto «non lo so» pur non avendo la base informativa per rispondere, il caso più costoso, perché indistinguibile dal successo. La terza è di allineamento tra l’agente e l’azienda: quanti documenti della base di conoscenza sono più vecchi dell’ultima modifica ai processi che descrivono. Se l’agente attinge a un sistema RAG, questa terza famiglia è quella che degrada più in fretta, perché non dipende dal modello ma dall’azienda, che cambia listini e policy senza avvisare nessuno.

Come si misura il degrado di un agente AI in produzione

La tecnica che funziona è banale e quasi nessuno la applica: un insieme fisso di casi di prova, cinquanta, cento domande reali con la risposta corretta congelata accanto, rieseguito a intervalli regolari e confrontato con l’esecuzione precedente. Non serve un framework: serve che la lista esista, che sia scritta con chi conosce il mestiere, e che il confronto avvenga a calendario, non quando qualcuno si insospettisce. È l’unico modo per trasformare un sospetto in un numero, e un numero in una decisione.

Vale la pena notare che questo non è solo buona pratica. L’AI Risk Management Framework del NIST, pubblicato il 26 gennaio 2023, organizza la gestione del rischio AI attorno a quattro funzioni, Govern, Map, Measure, Manage, dove misurare e gestire non sono attività di progetto ma di esercizio continuo. Chi vende un agente senza la parte «Measure» sta consegnando metà del sistema.

Canale diretto e referente unico: perché il ticket anonimo non basta

Le due voci sembrano dettagli organizzativi. Sono invece dirette conseguenze di come si guasta un agente. Un ticket in coda funziona quando il problema è auto-contenuto e descrivibile: «la fattura non si stampa». Su un agente la segnalazione tipica suona così: «ci sembra che risponda peggio di prima sulle domande di logistica». Non è un bug report, è un indizio, e per trasformarlo in diagnosi serve qualcuno che sappia già com’è configurato quel agente, quali fonti legge, quale prompt di sistema ha, cosa è stato cambiato nelle ultime due settimane.

Questo contesto non sta in un ticket: sta in una persona. Il referente unico non è una gentilezza commerciale, è un archivio. Ed è anche una scelta di efficienza misurabile: un primo livello anonimo su un agente AI produce quasi solo escalation, perché nessuno può risolvere al primo contatto un problema che richiede la storia della configurazione. Il canale diretto, una persona raggiungibile in modo asincrono ma nominale, elimina un passaggio che non aggiungeva niente.

C’è un secondo effetto, meno ovvio e più utile nel medio periodo: il referente diventa il posto dove si accumula il sapere su cosa in azienda l’agente fa bene e cosa non dovrebbe fare affatto. È materia che serve anche alla formazione del team interno, e che con un supporto a rotazione va perduta a ogni chiamata. Chi sceglie tra un agente chiavi in mano e uno self-service sta scegliendo, in buona parte, se questo archivio esisterà o no.

Aggiornamenti di configurazione e cambi di modello: il calendario che nessuno vi manda

Qui l’assistenza dedicata smette di essere una questione di servizio e diventa una questione di sopravvivenza operativa, perché il terreno sotto l’agente si muove per decisione di terzi. La pagina delle deprecation di OpenAI fissa i preavvisi minimi: almeno 6 mesi per i modelli generalmente disponibili, almeno 3 mesi per le varianti specializzate, e per i modelli in preview «much shorter notice», nell’ordine delle due settimane, con l’avvertenza esplicita di non usarli per carichi business-critical senza flessibilità di migrazione.

Sei mesi sembrano tanti. Diventano pochi appena si guarda il secondo calendario. Lo schedule dei ritiri di Microsoft Foundry, aggiornato al 2 settembre 2026, mostra tre cose che un contratto di licenza non vi dirà. La prima: le date non coincidono tra fornitori per lo stesso modello. Lo snapshot gpt-5-2025-08-07 è dato in shutdown da OpenAI l’11 dicembre 2026, mentre su Foundry lo stesso gpt-5 versione 2025-08-07 è indicato al 9 febbraio 2027. Due mesi di scarto sulla stessa cosa: se non sapete su quale delle due infrastrutture girate, non sapete quando scade il vostro agente.

La seconda: le finestre non sono uniformi. Sempre nello stesso documento, i modelli Fireworks in offerta standard per-token sono soggetti a un preavviso di 15 giorni prima del ritiro. La terza, la più insidiosa: la colonna «Replacement» è descritta come il bersaglio degli automatic upgrades al momento del ritiro. Significa che un agente può ritrovarsi, a data fissata, su un modello diverso da quello su cui è stato tarato, senza che nessuno abbia toccato una riga di configurazione. E non è teoria per il 2028: nel documento, gpt-4o (2024-05-13) è al 1 ottobre 2026 con sostituto gpt-5.1, o4-mini al 16 ottobre 2026, o1 e o3 al 21 ottobre 2026, e Claude Sonnet 4.5, Opus 4.5 e Haiku 4.5 sono tutti al 19 ottobre 2026. Sono settimane, non anni.

Ogni quanto va aggiornato un agente AI

Non esiste una cadenza universale, ma esistono due orologi che la determinano ed è ragionevole allinearsi al più veloce. L’orologio esterno è quello dei ritiri: chi presidia guarda i calendari dei fornitori con periodicità mensile e pianifica la migrazione prima della scadenza, verificando la nuova versione sui casi di prova della sezione precedente, perché un modello «migliore» sui benchmark può essere peggiore sul vostro dominio. L’orologio interno è quello dell’azienda: ogni volta che cambiano listini, policy, catalogo o procedure, la base di conoscenza dell’agente è disallineata da quel momento, non dal trimestre successivo. Il retraining periodico e la revisione della configurazione, in pratica, sono la manutenzione ordinaria di questi due orologi, un tema che approfondiamo lato tecnico nella manutenzione post-deployment e lato accordi nella gestione continua con il partner.

Su un agente con RAG, «retraining periodico» significa in concreto tre operazioni ricorrenti. La prima è la reindicizzazione della base di conoscenza a ogni cambio di listino, catalogo o policy: i documenti sostituiti vanno rimossi e reincorporati, altrimenti l’agente continua a recuperare la versione vecchia accanto a quella nuova. La seconda è la ri-taratura del prompt di sistema, che invecchia insieme ai processi che descrive, ruoli, escalation, cosa l’agente non deve fare. La terza è la riesecuzione dei casi di prova dopo ogni modifica, non a fine trimestre: è l’unico controllo che dice se l’intervento ha migliorato o rotto qualcosa. Il fine-tuning del modello, invece, è l’eccezione: nella grande maggioranza dei casi aziendali si aggiorna la conoscenza e la configurazione, non i pesi.

Chi risponde se l’agente sbaglia con un cliente

La domanda arriva sempre, e la risposta onesta è che la responsabilità verso il cliente finale resta dell’azienda che ha messo l’agente davanti a lui, e vale per tutti i processi aziendali in cui gli agenti lavorano già oggi. Il fornitore risponde di ciò che si è impegnato a fare, disponibilità, tempi di intervento, correzione, ma non si sostituisce all’azienda nel rapporto col cliente. Questo rende il presidio ancora più importante, non meno: se la responsabilità è vostra, l’unica cosa che potete negoziare è la velocità con cui l’errore viene trovato e chiuso.

Sul piano normativo il quadro europeo è già scritto, e va nella stessa direzione. L’articolo 72 dell’AI Act impone ai fornitori di sistemi ad alto rischio un sistema di monitoraggio successivo all’immissione sul mercato che raccolga e analizzi dati sulle prestazioni «throughout the operational lifetime» del sistema, con un piano incorporato nella documentazione tecnica e un template della Commissione previsto entro il 2 febbraio 2026. L’articolo 14 aggiunge il lato umano: chi sorveglia deve poter comprendere capacità e limiti del sistema, «rilevare e gestire anomalie, disfunzioni e prestazioni impreviste», restare consapevole dell’automation bias, la tendenza a fidarsi dell’output per abitudine, e disporre di un modo per interrompere il sistema in sicurezza. La sorveglianza umana continua non è un plus commerciale: per i sistemi che ricadono nell’alto rischio è un obbligo, e conviene sapere se il vostro caso d’uso ci ricade prima di firmare. Il perimetro e le scadenze li abbiamo mappati nella guida su cosa prevede l’AI Act e chi deve adeguarsi.

Assistenza o manutenzione di un agente AI: che differenza c’è

Si usano come sinonimi e non lo sono. La manutenzione agisce sul sistema: aggiorna versioni, ritara prompt, riallinea la base di conoscenza, migra il modello prima del ritiro. L’assistenza agisce sulle persone: risponde a chi in azienda ha un dubbio, riceve le segnalazioni, spiega perché l’agente ha risposto in un certo modo, forma chi lo usa. Servono entrambe e si alimentano a vicenda, le segnalazioni dell’assistenza dicono alla manutenzione dove intervenire, ma un contratto che copre solo la prima lascia gli utenti soli, e uno che copre solo la seconda lascia il sistema a invecchiare.

Assistenza agenti AI per le aziende: come si riconosce un servizio da una licenza

Alla fine il discriminante non è nel materiale commerciale, dove tutti scrivono «supporto dedicato». È in tre artefatti che esistono o non esistono. Il primo è un referto periodico con numeri confrontabili col periodo precedente: se il report mostra solo volumi e uptime, il degrado silenzioso non è presidiato. Il secondo è un calendario di scadenze dei modelli in uso, con la migrazione già pianificata. Il terzo è un nome e un canale per raggiungerlo. Se tutti e tre ci sono, state comprando un servizio; se manca il terzo, un abbonamento; se mancano i primi due, una licenza con un indirizzo email. Gartner, nello stesso comunicato del giugno 2025, segnala il fenomeno dell’agent washing: fornitori che rietichettano come agentico ciò che non lo è. Vale anche per l’assistenza, e questi tre artefatti sono il modo più rapido di verificarlo.

Assistenza agenti AI in azienda: come si presenta in pratica

È il modello con cui lavoriamo in Mimír: un affiancamento continuativo con un referente che conosce la configurazione, monitoraggio a cadenza fissa e aggiornamenti pianificati sui calendari dei fornitori, non una licenza da attivare e amministrare per conto proprio. Lo citiamo come esempio del modello descritto sopra, non come raccomandazione: i tre artefatti valgono per chiunque, noi compresi, e servono a valutare le offerte, anche la nostra.

Se state portando in produzione un agente e volete capire cosa serve presidiare nel vostro caso specifico, scriveteci per una consulenza: si parte sempre dai processi che avete, non dal software, e per orientarsi prima resta utile la lettura di base su cosa sono gli agenti AI e come funzionano davvero.

Fonti:

• SLA di Amazon Bedrock
• SLA di Vertex AI
• Anthropic — Service tiers (platform.claude.com)
• AgentSLA: Towards a Service Level Agreement for AI Agents
• ISO/IEC 25010 — Systems and software quality models
• AI Risk Management Framework del NIST
• pagina delle deprecation di OpenAI
• schedule dei ritiri di Microsoft Foundry
• articolo 72 dell’AI Act
• articolo 14 dell’AI Act — sorveglianza umana
• Regolamento (UE) 2024/1689 (AI Act) — testo ufficiale su EUR-Lex
• Gartner — comunicato del 25 giugno 2025 sui progetti di AI agentica