SLA agente AI aziendale: le soglie da mettere a contratto (checklist)

Chi firma per un agente AI in azienda firma quasi sempre due contratti senza accorgersene: uno con il fornitore del modello, che garantisce pochissimo, e uno con chi quell’agente lo costruisce e lo tiene in piedi. Il primo è pubblico, standardizzato e pieno di esclusioni. Il secondo è quello dove si decide davvero se, alle nove del mattino di un lunedì, l’agente risponde o no.

Uno SLA agente AI aziendale serio non è un numero di uptime copiato da un template cloud. È un capitolato che mette per iscritto quattro cose che un sistema basato su modelli linguistici può rompere in modi che il software tradizionale non conosceva: la disponibilità, la latenza, la qualità delle risposte quando il modello cambia sotto i piedi, e i tempi di ripristino quando il fornitore a monte ha un incidente. Se cerchi l’elenco delle domande da porre al partner prima della firma, quello sta nel nostro pezzo su quali garanzie chiedere prima di firmare: qui invece c’è il capitolato vero e proprio, con le soglie numeriche da scriverci dentro. Vediamo come si scrive ciascuna clausola, con soglie concrete, e cosa cambia tra tenersi tutto in casa e affidarlo a un partner in managed service.

In questo articolo scoprirai:

• Cosa significa SLA in ambito aziendale, e cosa cambia quando il servizio è un agente AI
• Differenza tra KPI e SLA in un contratto per agenti AI
• Cosa copre davvero lo SLA del fornitore di modello, e cosa lascia scoperto
• Uptime, latenza e accuratezza: le tre soglie di uno SLA agente AI aziendale
• Drift del modello e aggiornamenti di sicurezza: i tempi di intervento da mettere a contratto

Cosa significa SLA in ambito aziendale, e cosa cambia quando il servizio è un agente AI

SLA è la sigla di Service Level Agreement, in italiano «accordo sul livello di servizio»: un documento contrattuale che rende oggettivo e misurabile il livello di un servizio, stabilendo cosa il fornitore si impegna a garantire, come lo si misura e cosa succede se non ci riesce. AWS lo definisce come il contratto che descrive il livello di servizio che un fornitore promette di erogare, e ne distingue tre tipi: customer-level (tutti i servizi di un cliente), service-level (stesse condizioni per tutti i clienti dello stesso servizio) e multi-level (livelli differenziati). In ambito aziendale lo SLA non è documentazione tecnica: è la parte del contratto che, in caso di contenzioso, determina chi ha sbagliato.

SLA in ambito aziendale: cosa dice il Codice Civile

Nel diritto italiano lo SLA ricade negli obblighi contrattuali disciplinati dagli articoli 1218 e seguenti del Codice Civile sulla responsabilità per inadempimento: come ricorda LegalBlink, senza metriche specifiche e senza penali il documento resta una dichiarazione d’intenti. Il significato commerciale è esattamente questo: lo SLA trasforma una promessa in un’obbligazione con conseguenze economiche.

Che cos’è uno SLA informatico, e perché su un agente AI non basta più

Uno SLA informatico classico misura tre cose: disponibilità del sistema, tempo di risposta dell’assistenza, tempo di ripristino. Atlassian le riassume nei valori tipici, 99,9% di uptime, presa in carico entro 24 ore, tempi di risoluzione per gravità. Funziona, finché il servizio o è su o è giù.

Un agente AI rompe questo schema. L’applicazione può essere online, l’API può restituire 200, e l’agente può comunque fallire: sceglie lo strumento sbagliato, inventa un dato, oppure impiega novanta secondi per un’operazione che doveva sembrare istantanea. Nessuna di queste tre cose viene rilevata da un monitor di uptime. Se il capitolato si ferma alla disponibilità, l’azienda ha comprato la garanzia che il telefono squilli, non che qualcuno risponda in modo sensato. È il motivo per cui, come abbiamo argomentato a proposito dell’AI agent enterprise, il confronto fra fornitori fatto solo sul benchmark del modello è un confronto su metà del problema.

Differenza tra KPI e SLA in un contratto per agenti AI

È la domanda più frequente quando si apre il capitolato, e la confusione costa soldi. I tre termini che servono sono SLA, SLO e KPI, e stanno su piani diversi.

Lo SLA è l’accordo contrattuale: descrive il servizio, i livelli attesi, le responsabilità e le penali. Lo SLO (Service Level Objective) è l’obiettivo numerico dentro lo SLA, «uptime 99,9% su base mensile», «presa in carico entro 30 minuti». Il KPI è la metrica operativa che monitori per capire se stai rispettando l’obiettivo. Detto in breve: il KPI misura, lo SLO fissa la soglia, lo SLA stabilisce cosa succede se la soglia salta.

La distinzione più utile in pratica la fa la documentazione Microsoft sulla lettura degli SLA: lo SLA è il minimo garantito dal fornitore, lo SLO è l’affidabilità di cui i tuoi utenti hanno davvero bisogno. Non sono la stessa cosa e non vanno copiati l’uno dall’altro. Microsoft aggiunge un avvertimento che vale oro in un progetto con più fornitori AI: non moltiplicare fra loro le percentuali dei vari SLA per stimare la disponibilità complessiva, perché quel calcolo presume che i servizi si guastino in modo indipendente, cosa che quasi mai accade, e restituisce un sistema più affidabile di quanto sia.

Service level agreement: esempio di soglia scritta bene e scritta male

Scritta male: «il servizio garantisce elevata disponibilità e tempi di risposta rapidi». Non è misurabile, quindi non è esigibile. Scritta bene: «disponibilità mensile ≥ 99,5% calcolata sui minuti fatturabili, latenza p95 ≤ 15 secondi sui task interattivi misurata end-to-end, presa in carico delle segnalazioni di gravità 1 entro 30 minuti nelle ore di servizio, con service credit del 10% del canone mensile per ogni soglia mancata». La seconda si può contestare, la prima no. I KPI di monitoraggio che reggono la misura sono i soliti del facility IT, uptime, MTTR come tempo di risposta, MTTR come tempo di riparazione, MTBF, applicati però a eventi che nel software tradizionale non esistevano.

Cosa copre davvero lo SLA del fornitore di modello, e cosa lascia scoperto

Prima di scrivere il proprio capitolato conviene leggere quello che si eredita. Lo SLA pubblico di Azure OpenAI, per esempio, impegna Microsoft al 99,9% di uptime mensile sull’endpoint di inferenza, con service credit del 10% sotto quella soglia, 25% sotto il 99% e 100% sotto il 95%. Sembra molto. Poi si legge l’elenco delle esclusioni: latenza e qualità dell’output del modello, disponibilità del content filter, modifiche al tokenizer, feature in preview e problemi originati dal codice del cliente restano fuori. E una chiamata che risponde «429 Too Many Requests» conta comunque come servizio disponibile nella metrica di Microsoft.

Esclusioni e service credit nello SLA del fornitore di modello

Le conseguenze pratiche sono tre, e sono le stesse con qualunque fornitore. Primo: un mese da 30 giorni vale 43.200 minuti, quindi non è dovuto nulla finché il disservizio non supera i 43 minuti. Secondo: il credito è un accredito su fattura futura, non denaro, e non copre mancato fatturato né danno reputazionale. Terzo: il credito non arriva da solo, va richiesto entro una finestra che tipicamente va dai 30 ai 60 giorni dalla fine del mese di fatturazione, allegando log, timestamp, codici d’errore e la prova di aver implementato i retry richiesti. Chi non ha strumentato il monitoraggio prima dell’incidente non ha i dati per reclamare dopo.

Quanto spesso serve? StatusGator conta 420 disservizi di Anthropic da gennaio 2025, con una decina di eventi nelle sole prime due settimane di settembre 2026, quasi tutti risolti entro una o due ore ma con un caso di degradazione durato oltre quattro giorni. Non è un difetto di Anthropic in particolare: è la fisiologia di un mercato in cui la capacità di calcolo è il collo di bottiglia. Vale la pena tenerlo presente anche quando si valutano i costi delle API di Claude rispetto all’abbonamento: il prezzo per token non dice nulla sulla continuità.

Uptime, latenza e accuratezza: le tre soglie di uno SLA agente AI aziendale

Qui sta la differenza fra un capitolato copiato e uno scritto per un agente. Le tre soglie vanno definite separatamente, perché si rompono separatamente: sono il nucleo di quali garanzie chiedere prima di firmare.

Disponibilità. Va estesa oltre l’endpoint del modello: deve coprire l’agente, i connettori verso i sistemi interni e i tool esterni. Un agente che resta online ma perde l’accesso al CRM è fermo come se fosse spento. Attenzione alle promesse esagerate: c’è chi propone il «five nines», 99,999% di uptime, cioè 5,26 minuti di fermo all’anno. Su una catena che include un fornitore terzo di modelli quel numero non è credibile, e un partner che lo firma senza spiegare come lo raggiunge sta vendendo un impegno che non può mantenere.

Latenza. Va misurata end-to-end, routing, retrieval, validazioni, retry inclusi, non solo sul tempo di inferenza. Un template di SLA per agenti AI pubblicato da Wavect propone soglie separate per tipologia: task interattivi con p50 ≤ 5 secondi, p95 ≤ 15 secondi, p99 ≤ 30 secondi; task asincroni con p95 ≤ 5 minuti. Il p99 conta più della media, perché è lì che l’utente abbandona.

Accuratezza e allucinazioni: la soglia che manca in quasi tutti i capitolati

La terza soglia è quella che distingue uno SLA per agenti da uno SLA per software. Lo stesso template fissa il tasso di completamento riuscito a ≥ 98%, dove «riuscito» significa che l’agente ha raggiunto il risultato di business approvato, ha usato solo strumenti autorizzati e non ha prodotto allucinazioni materiali. Sul tool-use distingue fra ≥ 97% al primo tentativo e ≥ 99% come esito finale: la forbice separa i guasti transitori dai difetti sistemici. Sulle allucinazioni la soglia è zero eventi di gravità 1 non contenuti e ≤ 1% sul campione di qualità verificato. È anche il punto in cui si decide quanta supervisione serve a un agente autonomo.

Perché funzioni serve il pezzo che quasi nessuno negozia: la tracciabilità. Ogni esecuzione deve lasciare una traccia con identificativo univoco, versione del modello e del prompt, argomenti passati ai tool, esito e codice di fallimento, conservata in forma interrogabile (il template indica 90 giorni consultabili e 12 mesi in archivio). Senza tracce non si misura l’accuratezza, e senza misura la clausola sull’accuratezza non è esigibile. Vale anche per gli obblighi di documentazione previsti dall’AI Act, che chiedono di poter ricostruire come un sistema è arrivato a un output.

Drift del modello e aggiornamenti di sicurezza: i tempi di intervento da mettere a contratto

Il drift è l’unico guasto che non genera un alert da solo: l’agente continua a rispondere, semplicemente risponde peggio. La distinzione tecnica è fra data drift, cioè lo spostamento della distribuzione degli input, e model drift, cioè il degrado delle prestazioni del modello. Sugli LLM assume tre forme pratiche: prompt drift (cambia il modo in cui gli utenti scrivono), retrieval drift (la stessa domanda recupera documenti diversi, quindi cambia la risposta) e tool-distribution drift (cambia la quota di chiamate che dovrebbero scattare).

Si misura con soglie numeriche, e vanno scritte nel capitolato. Sui dati tabellari, secondo Future AGI il Population Stability Index sotto 0,1 indica stabilità, fra 0,1 e 0,2 uno scostamento moderato, oltre 0,2 uno scostamento che richiede intervento. Sugli embedding si usano la deriva coseno dei centroidi e il test MMD. La regola operativa che evita l’alert fatigue è non allertare mai sul solo drift degli input, ma sulla condizione congiunta di drift più calo misurabile del punteggio di valutazione.

Le quattro clausole sul drift da scrivere nello SLA dell’agente

Le clausole da pretendere sono quattro. Monitoraggio continuo: chi guarda le metriche, con quale frequenza, e con quale report verso il cliente. Tempo di intervento su drift confermato: non il tempo di risposta al ticket, ma il tempo entro cui il partner rimette la qualità sopra soglia, distinto per gravità. Pinning di versione e preavviso di deprecazione: il fornitore del modello può ritirare una versione o sostituirla, e un cambio di versione non annunciato è un cambio di comportamento dell’agente in produzione. Aggiornamenti di sicurezza: finestra massima per applicare patch su vulnerabilità critiche dei componenti e dei connettori, con tempi più stretti di quelli ordinari. Sono esattamente le voci che rendono la manutenzione post-deployment un lavoro continuativo e non un intervento a chiamata, e che vanno elencate nel contratto di gestione continua.

Ripristino dopo un incidente del fornitore: cosa deve garantire lo SLA dell’agente

Due episodi recenti mostrano perché la clausola di ripristino non può limitarsi al «riavviamo il servizio».

Il primo è la degradazione silenziosa della qualità. La status page di Claude documenta un incidente di «model output quality» causato da due bug separati e non correlati, con impatto su Claude Sonnet 4, Haiku 3.5, Opus 3 e 4.1: le finestre di impatto vanno dal 26 agosto al 5 settembre per un bug e dal 31 agosto al 4 settembre per l’altro, con la risoluzione completa annunciata solo il 17 settembre. Anthropic ha precisato di non aver mai degradato intenzionalmente la qualità e ha riconosciuto che a segnalare il difetto è stata la community, non il monitoraggio interno. Per un’azienda cliente significa questo: per giorni l’agente ha risposto peggio, nessun alert di uptime è scattato, e chi non aveva una valutazione automatica sulle proprie risposte non se n’è accorto.

Incidente di sicurezza e perimetro di esecuzione dell’agente

Il secondo è l’incidente di sicurezza reso pubblico da Anthropic il 30 luglio 2026, in cui tre modelli, Mythos 5, Opus 4.7 e un modello sperimentale non rilasciato, durante esercitazioni di cybersecurity hanno raggiunto Internet e violato i sistemi di tre organizzazioni reali. La causa dichiarata è «un malinteso» fra Anthropic e il partner di valutazione Irregular sulla configurazione dell’ambiente: i modelli avevano accesso alla rete pur essendo stati istruiti del contrario. Due delle tre organizzazioni non si erano accorte di nulla. Il punto per chi scrive un capitolato non è il comportamento del modello: è che un errore di perimetro nell’ambiente di esecuzione produce effetti reali su sistemi reali, e va coperto da clausole di isolamento, autorizzazione dei tool e notifica. Ne abbiamo parlato più a fondo nella guida completa a Claude e ai suoi rischi.

Cosa mettere a contratto, con gli ordini di grandezza da cui partire in negoziazione, non sono standard di settore, sono riferimenti iniziali da tarare sul processo. RTO e RPO espliciti per l’agente e per i dati di contesto: per un agente interattivo di supporto un RTO di 4 ore e un RPO di 15 minuti sulle conversazioni e sui dati di contesto sono un punto di partenza ragionevole, da stringere se l’agente sta su un processo che non tollera arretrato. Procedura di fallback verso un modello o un provider alternativo, con la degradazione funzionale dichiarata in anticipo e un tempo di attivazione dichiarato (indicativamente entro 30 minuti dalla conferma dell’incidente, se il fallback è automatico deve scattare entro pochi minuti). Notifica al cliente entro 1 ora dalla rilevazione per gli incidenti di gravità 1 e entro 4 ore per la gravità 2, indipendentemente dal fatto che l’origine sia il fornitore a monte, con aggiornamento di stato almeno ogni 4 ore finché l’incidente è aperto. Post-mortem scritto entro 5 giorni lavorativi dalla chiusura, con causa radice, cronologia e azioni correttive datate. E una clausola spesso dimenticata: cosa fa l’agente quando il modello non risponde, si ferma, degrada, o passa all’operatore. La scelta va decisa prima, non durante.

SLA agente AI self-hosted o managed service: cosa cambia nel capitolato

Con un agente self-hosted lo SLA verso l’utente interno lo scrivi tu e lo mantieni tu. Erediti il 99,9% del fornitore di modello, con tutte le esclusioni viste sopra, e devi costruirci sopra ogni cosa: monitoraggio della qualità, rilevamento del drift, reperibilità fuori orario, aggiornamento dei connettori quando cambia un’API a monte, gestione dei cambi di versione. Sono esattamente le attività che la licenza di un agente AI non include. Il vantaggio è il controllo pieno e nessuna dipendenza contrattuale da terzi. Il costo è che le competenze necessarie non sono quelle di un team IT tradizionale, e vanno disponibili tutti i giorni, non solo il giorno del rilascio.

SLA in managed service: cosa deve garantire il partner oltre al fornitore

Con un managed service il partner assume l’obbligazione verso di te e si prende in carico il rischio a monte. Attenzione però: se il partner si limita a ricopiare le esclusioni del fornitore di modello, non hai comprato nulla che tu non avessi già. Il valore c’è quando il partner garantisce livelli che il fornitore di modello non garantisce, latenza end-to-end, accuratezza, tempo di intervento sul drift, ripristino, assumendosene la responsabilità economica. È il discrimine che abbiamo usato anche nel confronto fra agente AI chiavi in mano e self-service e nell’analisi su quando conviene esternalizzare al partner.

Un’osservazione sui numeri che circolano. Si legge spesso che un minuto di downtime costa circa 5.600 dollari: è una cifra che compare di continuo nei materiali commerciali dei fornitori, sempre senza il documento originale a cui risalire. È una media vecchia, costruita su aziende molto diverse fra loro: non dice nulla sul costo del fermo nel tuo processo specifico, e usarla per dimensionare le penali è un errore. Il calcolo giusto è quello interno: quante pratiche al giorno passano dall’agente, quanto costa lavorarle a mano, quante ore di fermo il processo tollera prima di creare un arretrato che non recuperi. Da lì si ricavano le soglie, non da un benchmark di settore, ed è il primo esercizio da fare con chi ti segue, come spieghiamo parlando di cosa aspettarsi da un partner se sei una PMI.

Cosa sono gli SLA nei contratti di managed service, e cosa copre il canone Mimir

Negli accordi di managed service lo SLA è la parte che definisce l’obbligazione continuativa: non «cosa ti consegno», ma «a che condizioni te lo tengo in piedi». È la ragione per cui in Mimir il perimetro del servizio è scritto nel canone mensile e non nel preventivo di sviluppo: l’agente viene costruito una volta, ma monitoraggio, aggiornamenti, gestione dei cambi di versione del modello e intervento sugli incidenti sono attività che non finiscono mai. Accanto a questo, l’assistenza dedicata durante l’onboarding è la fase in cui le soglie vengono tarate sui processi reali dell’azienda invece che copiate da un modello standard, ed è lì che si scopre se il p95 a 15 secondi è largo o stretto per quel caso d’uso.

La checklist qui sotto è il capitolato minimo: copiala nel documento di gara o nella richiesta al fornitore, e chiedi che ogni riga sia riempita con un numero, non con un aggettivo.

• Perimetro, quali processi, quali canali, quali lingue, quali tool autorizzati; cosa è esplicitamente escluso.
• Disponibilità, percentuale mensile, metodo di calcolo (a tempo o a richieste), cosa include oltre all’endpoint del modello.
• Latenza, p50, p95, p99 per task interattivi e asincroni, misurati end-to-end.
• Accuratezza, tasso di completamento riuscito, tool-use al primo tentativo e finale, soglia sulle allucinazioni materiali.
• Drift, metriche monitorate, soglie di allerta, tempo di intervento per gravità, frequenza del report.
• Versioni del modello, pinning, preavviso di deprecazione, chi valida il passaggio a una nuova versione.
• Sicurezza, finestra di patch per vulnerabilità critiche, isolamento dell’ambiente, autorizzazione esplicita dei tool.
• Incidenti, tempo di notifica, RTO/RPO, fallback previsto, post-mortem scritto.
• Escalation, livelli di gravità, referenti nominati, reperibilità e orari di servizio.
• Osservabilità, tracce conservate, accesso del cliente ai log, dashboard delle metriche SLA.
• Rimedi, service credit per soglia e per gravità, tetto mensile, procedura e finestra di reclamo.
• Uscita, handover di prompt, configurazioni e dati, tempi e formato di consegna.
• Revisione, cadenza di riesame delle soglie, perché un agente in produzione da sei mesi non ha gli stessi carichi del primo giorno.

Se stai valutando come portare un agente AI in azienda e vuoi

Se stai valutando come portare un agente AI in azienda e vuoi qualcuno che ti accompagni nell’adozione, dalla definizione delle soglie all’esercizio quotidiano, puoi rivolgerti a Tinke per una consulenza. Il punto di partenza non è scegliere il modello, ma capire quali livelli di servizio il tuo processo richiede davvero: da lì in poi il capitolato quasi si scrive da solo.

Se prima vuoi inquadrare il tema, parti dalla nostra guida su cosa sono gli agenti AI e come funzionano, e da quella su come si creano agenti AI su misura per la propria azienda.

Fonti:

• AWS, What is a Service Level Agreement
• Atlassian, Gli SLA nel service management
• Microsoft Learn, Come leggere gli SLA di Azure
• Redress Compliance, Azure OpenAI SLA coverage 2026
• StatusGator, Storico dei disservizi Anthropic
• Beam AI, SLA per agenti AI enterprise
• Wavect, Template di SLA per agenti AI
• Future AGI, Model drift e data drift
• Claude status page, Incidente model output quality