L'acquisto di IA in azienda segue un copione noto: qualcuno mostra una demo, il sistema risponde bene tre volte di fila, la sala annuisce e si firma. Nessuno apre la scheda dell'accordo sul livello di servizio. Sei mesi dopo, un martedì mattina, l'agente che risponde ai clienti smette di rispondere —e lì comincia la conversazione che andava fatta prima di firmare: chi lo aggiusta, in quanto tempo, e cosa succede se non lo aggiusta?
La tesi in una frase: scegli il fornitore per la demo e ci convivi per il supporto. E lo SLA che credi di aver comprato di solito fallisce su tre punti insieme: non copre il piano che stai usando, misura la disponibilità invece del fatto che il sistema faccia bene il suo lavoro, e non dice assolutamente nulla su quanto ancora esisterà il modello da cui dipende la tua operatività.
Il supporto e lo SLA del tuo fornitore di IA non coprono quello che credi
Partiamo dalla cosa più basica e meno verificata: quasi nessun piano d'ingresso porta con sé uno SLA. L'impegno sulla disponibilità vive nel contratto enterprise, e tutti gli altri clienti operano col miglior sforzo del fornitore e un forum. Non è un sospetto: è scritto sulle loro pagine.
In OpenAI, il 99,9% di disponibilità e gli impegni di latenza sono legati allo Scale Tier, e la loro stessa pagina lo dice senza giri di parole: è un'offerta disponibile per i clienti Enterprise, a cui si accede parlando con le vendite. Il pagamento a consumo ordinario quell'impegno non ce l'ha. In più, il veicolo cambia con la generazione di modello: lo Scale Tier si applica ai modelli precedenti a GPT-5.6, e da lì in poi la conversazione si sposta sul Reserved Tier. Se il tuo accordo sul livello di servizio è legato a un prodotto che va in pensione insieme al modello, la tua copertura ha una data di scadenza anche se sulla carta non c'è scritta.
Il caso di n8n è ancora più netto, perché mette un prezzo al confine. Il suo piano Business costa 667 € al mese con fatturazione annuale, e sulla sua stessa pagina prezzi si legge che il Business è un'opzione self-serve e che il supporto dedicato sta solo in Enterprise. Tradotto: puoi pagare quasi ottocento euro al mese e il tuo canale di supporto ufficiale resta il forum della community. Non è un abuso —è pubblicato ed è coerente col loro modello— ma è esattamente il tipo di dettaglio che nessuno guarda nella riunione d'acquisto e che salta fuori il giorno in cui il flusso critico cade.
Uno SLA misura che sia acceso, non che azzecchi
Qui c'è il punto che costa più caro, perché è concettuale e non si aggiusta pagando di più. Un accordo sul livello di servizio di IA misura la disponibilità e, con un po' di fortuna, la latenza. La pagina Scale Tier di OpenAI, per esempio, pubblica impegni di velocità del tipo «99% sopra i 50-100 token al secondo», misurati sulla latenza mediana in finestre di cinque minuti. È un impegno serio e verificabile. E non dice niente su quanto la risposta fosse corretta.
Portalo all'estremo per vederlo chiaro: un modello che risponde sciocchezze a tutta velocità e senza mai cadere raggiunge il 99,9% con lode. Lo SLA è soddisfatto; la tua operatività, rotta. La qualità —che l'agente classifichi bene, che non inventi, che non risponda un'assurdità a un cliente— non sta in nessun contratto di infrastruttura, perché non è un problema di infrastruttura. È tuo. Ed è per questo che il lavoro di fissare la soglia accettabile e misurarla con casi reali non si delega al fornitore.
| Cosa credi che copra lo SLA | Cosa copre davvero | Chi risponde |
|---|---|---|
| Che il sistema funzioni | Che il servizio sia disponibile | Il fornitore, con crediti |
| Che risponda in fretta | A volte, e solo sui piani alti | Il fornitore, se l'hai firmato |
| Che risponda bene | Niente. La qualità non sta nello SLA | Tu |
| Che il modello continui a esistere | Niente. Quello va con la politica di ritiro | Tu, migrando |
| Che la tua integrazione non si rompa | Niente. Anche i parametri si deprecano | Tu |
Le ultime due righe sono quelle che sorprendono, e meritano una sezione a parte.
L'orologio che nessuno guarda: quanto vive il modello da cui dipendi
Il tuo sistema non dipende da «l'IA»: dipende da un modello concreto, con nome e versione, che un giorno viene ritirato. Anthropic lo documenta con una chiarezza che si apprezza e che conviene leggere per quello che è —un impegno minimo, non una promessa di permanenza—: avvisa con almeno 60 giorni di anticipo prima di ritirare un modello pubblicato ai clienti con deployment attivi.
Sessanta giorni sembrano tanti finché non li guardi sul calendario vero. Il loro stesso storico dei ritiri lo mostra: Claude Opus 4.1 è stato segnato come obsoleto il 5 giugno 2026 e ritirato il 5 agosto 2026. Claude Sonnet 4 e Opus 4 sono stati annunciati il 14 aprile 2026 e ritirati il 15 giugno. Due mesi, dall'avviso allo spegnimento. In quel tempo devi accorgertene, provare il sostituto sui tuoi casi reali, vedere cosa si degrada, sistemare i prompt che dipendevano dal comportamento del modello vecchio e rilasciare. Se la tua operatività scopre la mail di avviso al quarantesimo giorno, non hai due mesi: hai tre settimane.
E c'è una sfumatura che rompe pianificazioni intere: la data dipende da dove compri. La documentazione di Anthropic segnala che le piattaforme gestite dai partner —Amazon Bedrock e Google Cloud— fissano i propri calendari di ritiro, quindi lo stesso modello può avere stati e date diversi a seconda di dove lo consumi. Se il tuo contratto cloud e il tuo contratto di modello sono distinti, hai due orologi e nessuno dei due ti avvisa dell'altro.
La versione fine del problema non è nemmeno il modello: sono i parametri. Anthropic documenta che «temperature», «top_p» e «top_k» sono obsoleti a partire da Claude Opus 4.7 e restituiscono un errore 400 se li imposti a un valore diverso da quello predefinito. Tradotto: una riga di codice che funzionava da due anni passa a rompere la chiamata. Non è un'interruzione del servizio —lo SLA resta immacolato— ma il tuo agente ha smesso di lavorare come prima.
Le cinque domande che invece vanno fatte prima di firmare
Non serve un ufficio legale per blindarsi. Servono cinque domande, per iscritto, e conservare le risposte:
- Lo SLA si applica al mio piano? E se no, quanto costa il piano che invece ce l'ha. Molte volte la risposta trasforma un acquisto economico in una decisione diversa.
- Cosa misura esattamente e come si reclama? Disponibilità mensile, latenza, entrambe. E soprattutto: i crediti sono automatici o devo reclamarli io, con prove ed entro una finestra? Se è la seconda —e di solito lo è— qualcuno del tuo team deve stare a monitorare per poter reclamare.
- Qual è il canale di supporto reale e il suo tempo di risposta? Forum, mail o una persona con nome e cognome. Un tempo di risposta messo per iscritto vale più di un logo «supporto 24/7» sul sito.
- Qual è la politica di ritiro dei modelli e quanto preavviso danno? E con la risposta in mano: il mio team ha la capacità di migrare e rivalidare in quel tempo, con i miei casi reali?
- Cosa succede ai miei dati se me ne vado? Formato di uscita, tempi di cancellazione e se il fornitore addestra con quello che gli mandi. È la domanda che mette più a disagio e quella che rivela più in fretta con chi hai a che fare.
Quello che nessuno SLA ti darà: il turno di guardia
Anche firmando il miglior contratto del mercato, resta un buco che nessun fornitore copre ed è quello che fa male davvero. Quando il tuo agente smette di funzionare, di norma non è il fornitore a essere caduto: è un'API qui accanto che ha cambiato un campo, è il volume che si è triplicato, è qualcuno che ha toccato un prompt o è il caso raro che finalmente è arrivato. Lì non c'è nessuno da chiamare. La risposta è tua.
Significa quattro cose per niente glamour, che sono esattamente il lavoro di operare IA: qualcuno che sorvegli e se ne accorga prima del cliente, qualcuno di guardia con il permesso di fermare il sistema, una procedura scritta di cosa si fa quando fallisce —la manutenzione delle automazioni non è opzionale, è metà del progetto— e un quadro di controllo che decida chi può disattivare cosa, che è di questo che parla la governance e il controllo dell'automazione. Se questi quattro pezzi non hanno un proprietario, il tuo SLA è un bel foglio di carta.
La nostra posizione è semplice e poco commerciale: lo SLA del fornitore copre la sua parte, e la sua parte è la più piccola. Quella grande —che il sistema faccia bene il lavoro, che qualcuno se ne accorga quando smette di farlo e che il business non si fermi mentre si aggiusta— è una funzione operativa continua che va montata. È esattamente quello che facciamo con la gestione degli incidenti degli agenti IA: turno, procedura, contenimento e postmortem, perché la caduta sia un incidente gestito e non una mattinata persa.
La conclusione, senza fronzoli
Uno SLA è un trasferimento di rischio molto parziale e molto ben delimitato: il fornitore ti restituisce dei crediti se il suo servizio non è stato disponibile. Non ti restituisce il cliente che se n'è andato, né la chiusura che è slittata, né le tre settimane che ti è costato migrare di modello di corsa. Leggilo capendo questo e firmerai meglio. Leggilo aspettandoti che ti protegga da tutto e la sorpresa arriverà un martedì mattina.
Gli altri scelgono il fornitore per la demo e scoprono il supporto quando non si torna più indietro. Tu puoi fare cinque domande prima di firmare e montare il turno di guardia che nessun contratto include. Non è glamour. È quello che fa sì che il sistema funzioni ancora il martedì.