Sul tavolo c’è il contratto, e il fornitore ha appena detto la frase che rassicura tutti: «garantiamo il 99,9%». È un numero vero, probabilmente onesto, e riguarda la cosa sbagliata. Misura che l’API risponda, non che l’agente faccia bene il suo lavoro: un sistema può stare in piedi tutto il mese e nel frattempo sbagliare un ordine su dieci, smettere di restituire JSON valido, chiamare il tool sbagliato. Nessuna di queste cose accende un allarme di disponibilità.
Uno SLA agente AI serio si scrive con numeri diversi, e sono cinque famiglie: disponibilità, tempo di risposta, qualità dell’output, tracciabilità, tempi di intervento. Qui sotto trovi le soglie da mettere nero su bianco, i valori realistici da cui partire in trattativa, le clausole che quasi nessun contratto contiene e i segnali che dicono di non firmare. Se sei ancora nella fase precedente, capire cosa chiedere a voce, abbiamo scritto le 10 domande da fare al partner prima di firmare. Questo pezzo viene dopo: sono le risposte che devono finire nell’allegato tecnico.
In questo articolo scoprirai:
- Il 99,9% che compri dal cloud non copre il comportamento dell'agente
- Uptime nello SLA di un agente AI: la percentuale e i minuti di fermo che stai accettando
- Tempo di risposta: chiedi i percentili, non la media
- Accuracy minima e drift: come si scrive una soglia di qualità verificabile
- Log, audit trail e retention: sei mesi sono il pavimento di legge, non un buon SLA
Il 99,9% che compri dal cloud non copre il comportamento dell’agente
Gli SLA dei provider di modelli sono SLA di infrastruttura. La SLA di Vertex AI promette ≥99,9% mensile su training, deployment e batch prediction, e scende a ≥99,5% sulla online prediction di modelli custom con almeno due nodi; Amazon Bedrock paga un credito del 10% sotto il 99,9% e del 100% sotto il 95%. Sono impegni concreti, ma coprono la raggiungibilità dell’endpoint, non la stabilità del comportamento.
James Dawson di endjin lo ha descritto bene in un’analisi di agosto 2026: un aggiornamento silenzioso del modello, una modifica al system prompt del provider o uno spostamento delle soglie di sicurezza possono peggiorare materialmente il risultato di business mentre «la SLA non è in funzione. Nulla è rotto». Il costo, nota Dawson, è doppio: prima paghi token per fare la cosa sbagliata, poi ne paghi altri per capire perché.
Version pinning e preavviso: la clausola che manca in quasi tutti i contratti
La contromisura è contrattuale, non tecnica, e va scritta in tre righe: il fornitore dichiara la versione datata del modello in produzione (non l’alias), si impegna a non cambiarla senza preavviso scritto, e ti riconosce il diritto di ri-testare su un ambiente di staging prima che il cambio arrivi ai tuoi utenti. I riferimenti pubblici esistono: Anthropic dichiara almeno 60 giorni di preavviso prima del ritiro di un modello rilasciato pubblicamente, Opus 4.1, deprecato il 5 giugno 2026, è stato ritirato il 5 agosto. Chiedi al partner lo stesso ordine di grandezza, più una finestra di change freeze nei periodi critici del tuo business. Chi rivende un modello di terze parti senza mai nominare la versione sta assumendo un rischio che poi diventa tuo: è la stessa dinamica del vendor lock-in sugli agenti AI, vista dal lato della qualità.
Uptime nello SLA di un agente AI: la percentuale e i minuti di fermo che stai accettando
Le percentuali vanno tradotte in minuti, perché è lì che si capisce cosa si sta firmando. Su un mese standard: 99,5% significa circa 3 ore e 36 minuti di fermo tollerato, 99,9% scende a 43 minuti, 99,95% a poco più di 21 minuti. Su base annua il 99,9% vale 8 ore e 46 minuti. Il salto di prezzo tra un livello e l’altro è reale, quindi la domanda giusta non è «qual è il massimo che riesco a ottenere» ma «quanto mi costa un’ora di agente fermo in quel processo».
Un agente che smista ticket interni sopravvive benissimo a un 99,5%. Un agente che risponde ai clienti in orario commerciale o che chiude ordini no: lì 99,9% è la base, con reperibilità dichiarata sulla fascia oraria che ti serve davvero. Ha senso differenziare la soglia per componente, inferenza, integrazioni, pannello di controllo, invece di applicare un numero unico a tutto lo stack.
Le esclusioni che svuotano la percentuale
La parte che conta di un SLA di disponibilità è l’elenco delle esclusioni. Google esclude esplicitamente le funzionalità pre-GA, i problemi causati da software del cliente, le quote di sistema e l’uso di modelli oltre il ciclo di vita raccomandato; AWS esclude azioni e omissioni del cliente, configurazioni di rete e mancato rispetto della documentazione. Sono esclusioni ragionevoli in un contratto cloud, molto meno se il tuo fornitore le ricopia per coprirsi su cose che dipendono da lui: se l’agente si ferma perché è saturata una quota che gestisce il partner, quel fermo deve contare. Verifica poi chi misura: uptime dichiarato dal fornitore sulla base dei propri log non è la stessa cosa di un monitoraggio indipendente con endpoint di health check verificabile anche da te. La differenza si sente il giorno della contestazione.
Tempo di risposta: chiedi i percentili, non la media
La media dei tempi di risposta è il numero più inutile del documento. Il manuale SRE di Google lo dice senza giri di parole: le medie nascondono la coda lunga, mentre i percentili mostrano cosa succede davvero agli utenti, e conviene tenere un margine tra l’obiettivo pubblico e la prestazione reale, perché «gli utenti si basano sulla realtà di ciò che offri, non su quello che dici di fornire». Tradotto in clausola: ogni soglia di latenza va scritta come p50, p95 e p99, mai come valore medio. Su come si misurano davvero questi percentili in produzione abbiamo scritto la guida su osservabilità degli agenti AI, metriche, log e SLO: lì si misura, qui interessa come quei numeri diventano una clausola esigibile.
I valori di partenza in circolazione sono coerenti tra loro. Il glossario di MavenAGI indica sotto i 2-5 secondi per la chat e sotto i 500 ms per la voce; il template di SLA per agenti pubblicato da Wavect a luglio 2026 propone per i task interattivi p50 ≤ 5 secondi, p95 ≤ 15 secondi, p99 ≤ 30 secondi, e per quelli asincroni p95 ≤ 5 minuti. Sono punti di partenza negoziali, non standard di settore: vanno tarati sul processo.
Dove si misura la latenza in uno SLA per agenti AI
Due dettagli che cambiano il senso della clausola. Primo: definisci dove si misura il tempo, dal momento in cui la richiesta entra nel tuo sistema o da quando arriva al modello? Se il fornitore misura solo la seconda tratta, tutta la latenza delle integrazioni, del recupero documenti e dei tool sparisce dal conteggio. Secondo: per un agente che esegue catene di azioni, il tempo che conta è quello di completamento del task, non quello del primo token. Un agente che inizia a rispondere in 400 ms e chiude l’operazione in tre minuti ha una latenza percepita ottima e un tempo di ciclo pessimo. Metti entrambi.
Accuracy minima e drift: come si scrive una soglia di qualità verificabile
Qui si separa un contratto vero da una brochure. Una clausola di accuracy ha senso solo se il contratto definisce tre cose: su quale insieme di casi si misura, chi giudica, con che frequenza. Senza il campione di riferimento, un golden set di richieste reali con la risposta attesa, congelato e concordato, «accuratezza minima del 95%» è una frase, non un obbligo. La ricerca lo conferma: il paper AgentSLA di Jouneaux e Cabot (novembre 2025) parte proprio dalla constatazione che manca consenso su come definire la qualità di un agente, e propone un modello basato su ISO/IEC 25010 più un linguaggio per scrivere SLA verificabili. Il passaggio da «modello come servizio» ad «agente come servizio» ha reso insufficienti le metriche di sempre.
Le soglie di accuracy da mettere nello SLA dell’agente AI
Le soglie che si vedono nei template più seri: task completati con successo ≥ 98% su base mensile, tool-use corretto ≥ 97% al primo tentativo e ≥ 99% dopo retry, allucinazioni materiali ≤ 1% del campione valutato e zero eventi non contenuti di severità 1. Aggiungi il tasso di escalation a un umano, che va dichiarato e non nascosto: un agente che risolve il 70% delle richieste e passa pulitamente il resto è molto meglio di uno che ne risolve il 90% e sbaglia il 10% in silenzio.
Drift: la verifica periodica che rende esigibile la clausola
Sul drift, la clausola operativa è la frequenza della verifica: un ricalcolo settimanale del golden set con report scritto e soglia di allerta è il minimo per un agente in produzione su un processo che conta. Mensile va bene solo per usi interni a basso impatto. Se il fornitore non ha un modo per accorgersi che la qualità sta scendendo prima che te ne accorga tu, quella parte del contratto non è esigibile, ed è la stessa ragione per cui la manutenzione post-deployment non è un extra ma il cuore del servizio.
Log, audit trail e retention: sei mesi sono il pavimento di legge, non un buon SLA
La retention dei log è l’unico punto dove non parti da zero: c’è una norma, e vale la pena sapere cosa prevede l’AI Act e chi deve adeguarsi. L’articolo 19 dell’AI Act impone ai fornitori di sistemi ad alto rischio di conservare i log generati automaticamente «per un periodo appropriato alla finalità prevista, di almeno sei mesi», salvo termini più lunghi previsti da altre norme, protezione dei dati personali in testa, e regole specifiche per gli intermediari finanziari. Sei mesi, quindi, è il minimo legale per una parte dei casi, non l’obiettivo contrattuale.
Per un agente aziendale la retention utile è di 12-24 mesi, e la ragione è pratica prima che normativa: una contestazione di un cliente su un’operazione di aprile va ricostruita a settembre. Ma la durata conta meno del contenuto. Un log da cui non si ricostruisce la decisione è un file che occupa spazio.
Cosa deve contenere ogni riga di log di un agente AI
Quello che deve esserci, riga per riga: input ricevuto, versione esatta del modello e del prompt usati in quel momento, documenti recuperati, ogni chiamata a strumenti esterni con parametri ed esito, output prodotto, eventuale intervento umano, timestamp e costo. La versione del prompt e del modello è la voce che salta più spesso e serve più di tutte, perché è l’unico modo di dimostrare che il comportamento è cambiato dopo un aggiornamento. Servono poi due diritti espliciti: l’export in formato aperto in qualsiasi momento e la restituzione completa entro un termine certo alla cessazione del contratto. Su dove risiedono quei log e chi può leggerli si applicano le regole generali dell’AI Act per gli agenti in azienda e il tema più ampio degli agenti sicuri, dove il modello da solo non basta.
Tempi di intervento: severity, MTTA e MTTR con numeri che significano qualcosa
Un contratto che promette «assistenza tempestiva» non ha un tempo di intervento. Servono tre elementi: una scala di gravità definita con esempi tuoi, un tempo di presa in carico (MTTA) e un tempo di ripristino (MTTR) per ciascun livello, e il canale su cui vale l’orologio. La classificazione operativa più diffusa, ripresa anche dalla guida agli SLA per SOC di UnderDefense (marzo 2026), lavora su quattro livelli con MTTR di 30 minuti per i critici, 2 ore per gli alti, 4 ore per i medi e 8 per i bassi.
Cosa significa davvero uno SLA a 4 ore
Sul termine che genera più confusione: «SLA a 4 ore» quasi sempre indica il tempo entro cui il fornitore deve risolvere, o almeno mitigare, un incidente di gravità media, e in molti contratti nasconde due asterischi, vale solo in orario lavorativo e l’orologio parte dall’apertura formale del ticket, non da quando il problema si è manifestato. Se il tuo agente lavora anche di sabato, un MTTR di 4 ore in 9-18 dal lunedì al venerdì significa che un guasto del venerdì sera si risolve lunedì a mezzogiorno.
Per un agente conversazionale aggiungi una soglia che i contratti IT classici non hanno: il tempo di presa in carico umana quando l’agente passa la mano. Il template Wavect propone p95 ≤ 15 minuti sull’acknowledgement. E definisci cosa succede prima ancora dell’intervento: il comportamento di fallback. Un agente che si degrada in modo controllato, risposta di cortesia, coda verso un operatore, nessuna azione a metà, vale più di un MTTR aggressivo su un sistema che quando cade lascia operazioni incomplete. Molte di queste soglie andrebbero fissate già nell’onboarding dei primi 30 giorni, quando i volumi reali sono ancora osservabili senza danno.
Penali, service credit e uscita: cosa succede davvero se il fornitore sfora
Le percentuali senza conseguenze sono dichiarazioni d’intenti. Il meccanismo standard è il service credit a scaglioni, e i due riferimenti pubblici danno la misura: Google riconosce il 10% della fattura tra 99% e 99,9%, il 25% tra 95% e 99%, il 50% sotto il 95%, con un massimo del 50% mensile, richiesta entro 30 giorni dall’evento e accredito entro 60; AWS su Bedrock arriva al 100% di credito sotto il 95%. Nei modelli pensati per l’AI si aggiungono penali sulla qualità: 10% di credito per ogni obiettivo core mancato con un cap del 25% mensile nel template Wavect, oppure 5% ogni 0,1% di uptime sotto soglia e 10% se l’MTTR sfora di oltre il 50% nello schema UnderDefense.
Due avvertenze, però. La prima: un credito sul canone non è un risarcimento del danno, e nella maggior parte dei contratti è l’unico rimedio previsto. Se l’agente gestisce un processo il cui fermo costa molto più del canone mensile, il credito è un gesto simbolico e il valore vero sta altrove. La seconda, ed è quella che conta di più: pretendi la clausola di uscita per inadempimento ripetuto. Tre mesi di violazione in sei mesi mobili, o tre violazioni in 90 giorni, danno diritto al recesso senza penali e con restituzione di dati, log e configurazioni.
I red flag: «best effort», soglie senza misura, esclusioni che coprono tutto
Quattro segnali che valgono uno stop. «Best effort» o «impegno di mezzi» al posto di un numero: significa nessun obbligo. Una soglia senza metodo di misura e senza chi la misura: non è esigibile in contraddittorio. Le esclusioni del fornitore di modelli ricopiate integralmente nel contratto di servizio: il partner ti sta girando un rischio che ha scelto lui. E l’assenza totale di una clausola sul cambio di versione del modello, che dopo la sezione sul version pinning sai già dove porta.
Come lo scriviamo noi di Mimir, e perché lo mettiamo per iscritto
Noi vendiamo un servizio, non solo un agente che gira. Significa che lo SLA non è un allegato che si scarica: si scrive durante l’assessment, sul processo specifico del cliente, perché la soglia giusta per un agente che qualifica lead non è quella di un agente che risponde a un cliente in attesa. Quello che è fisso è il metodo: soglie di disponibilità e di latenza espresse in percentili, un golden set di casi reali concordato prima del go-live e ricalcolato con cadenza fissa, versione del modello dichiarata e nessun cambio in produzione senza preavviso e senza un giro di test, log completi ed esportabili con retention concordata sopra il minimo dell’AI Act, livelli di gravità con tempi di presa in carico e ripristino scritti accanto.
L’onboarding assistito, la voce che manca negli SLA per agenti AI
C’è una parte che non compare quasi mai negli SLA e che per noi conta quanto le altre: l’onboarding assistito. Nei primi mesi un agente non ha bisogno di un numero di telefono per le emergenze, ha bisogno di qualcuno che guardi i log insieme a te, riconosca i casi che sta sbagliando e li corregga prima che diventino un ticket. È il motivo per cui trattiamo l’affiancamento come parte del servizio e non come un extra a consumo, l’abbiamo raccontato parlando di cosa aspettarsi da un partner AI e di quando conviene il chiavi in mano rispetto al self-service. Non pubblichiamo un listino di soglie perché sarebbe un numero finto: le percentuali le fissiamo quando sappiamo cosa deve fare l’agente e quanto costa un’ora di fermo in quel processo.
Se stai valutando un progetto e vuoi capire quali garanzie ha senso chiedere, a noi o a chiunque altro, puoi parlarne con noi di MIMIR: partiamo dal processo, mettiamo per iscritto le soglie che reggono e ti diciamo apertamente quelle che non possiamo garantire. Se invece vuoi prima capire il terreno, la nostra guida su cosa sono e come funzionano davvero gli agenti AI è il punto di partenza migliore.
Fonti:
- Google Cloud — SLA di Vertex AI
- AWS — Amazon Bedrock Service Level Agreement
- endjin — Your Cloud AI SLA Tells You Less Than You Think (James Dawson, 5 agosto 2026)
- Anthropic — Model deprecations
- Google SRE Book — Service Level Objectives
- MavenAGI — AI Service Level Agreement (glossario)
- Wavect — AI agent SLA template (luglio 2026)
- UnderDefense — Guida agli SLA per AI SOC (marzo 2026)
- Jouneaux, Cabot — AgentSLA (arXiv, novembre 2025)
- AI Act — Articolo 19, conservazione automatica dei log
