Soluzione · AI Operations
Il tuo fornitore di IA cadrà. La domanda non è se, è cosa fa la tua operatività in quella mezz'ora.
Monitorare ti dice che qualcosa non va. La disponibilità è ciò che fa uscire il lavoro mentre non va: secondo percorso, modo degradato, code che assorbono il colpo e un obiettivo di ripristino concordato per caso d'uso. Montiamo questa funzione e la operiamo.
Il problema
Tratti un fornitore esterno come se fosse una costante della tua architettura.
- Se il tuo fornitore di modello ha una mezz'ora storta, tu hai una mezz'ora storta. Non c'è un secondo percorso e nessuno ha mai verificato se potrebbe esserci.
- Tutti gli agenti parlano con lo stesso fornitore, con la stessa chiave e contro la stessa quota. Un picco nell'agente di marketing consuma il limite dell'agente che fattura.
- Quando il modello restituisce errore, il processo non degrada: si ferma. Non c'è risposta parziale, né coda, né «questo lo risolviamo in dieci minuti»: c'è una schermata bianca e un cliente che aspetta.
- I ritentativi, dove esistono, sono immediati e in loop. Quando il fornitore è saturo, il tuo sistema gli aggiunge carico e allunga la propria caduta.
- Nessuno ha messo per iscritto quanto può restare fermo ogni caso d'uso. La chat del sito e il sistema che emette fatture sono trattati allo stesso modo, e non valgono lo stesso nemmeno da lontano.
- Sai che c'è stato un incidente perché te l'ha detto un cliente o perché qualcuno ha visto per caso la pagina di stato del fornitore. L'avviso è arrivato da fuori.
- Il piano per una caduta lunga vive nella testa di una persona. Se la caduta capita un venerdì sera e quella persona è in ferie, il piano non esiste.
Il costo di lasciare tutto com’è
Hai messo nel percorso critico della tua operatività un fornitore esterno di cui non controlli lo stato, e l'hai fatto senza piano B, senza limiti e senza un accordo interno su quanto ci si può fermare. Si paga in tre modi. Il primo è diretto: ogni incidente del fornitore è un incidente tuo, con la sua coda di lavoro arretrato e il suo cliente arrabbiato. Il secondo è peggio perché non si vede: senza isolamento né controllo di quota, un problema piccolo in un sistema secondario si porta via uno critico, e la diagnosi costa ore. E il terzo è di credibilità: quando la direzione chiede quanto può restare fermo questo, la risposta onesta oggi è «non lo sappiamo», e quella risposta è quella che blocca il prossimo progetto di IA.
La soluzione
Montiamo la continuità come funzione: secondo percorso, degrado controllato e un obiettivo concordato per caso d'uso
- 1Partiamo dall'accordo, non dall'architettura: quali casi d'uso ci sono in produzione, quanto può restare fermo ognuno senza danno reale e cosa si fa nel frattempo. Quell'obiettivo si firma con il business, non lo decide l'IT da solo, perché è una decisione di rischio e di costo —l'alta disponibilità si paga.
- 2Montiamo il secondo percorso. Un fornitore alternativo o un modello alternativo per i casi che lo giustificano, con l'instradamento pronto e provato, non disegnato in uno schema. Il percorso secondario può dare qualità peggiore: quello si misura prima e si decide se conviene, invece di scoprirlo il giorno della caduta.
- 3Definiamo il degrado controllato, che è il pezzo che quasi nessuno ha. Cosa fa il sistema quando l'IA non è disponibile: rispondere con la parte deterministica, accodare e comunicare il tempo, passare alla persona in reperibilità o restituire una risposta onesta. Tutto prima della schermata bianca.
- 4Mettiamo limiti e code con criterio. Quota e chiave separate per sistema perché un picco non si mangi il budget di un altro, ritentativi con attesa crescente invece di loop che aggravano la caduta del fornitore, e una coda che assorbe il colpo e rielabora quando il servizio torna, senza perdere lavoro per strada.
- 5Isoliamo i guasti. Un agente che si impianta non deve bloccare l'intero processo: circuit breaker per dipendenza, tempi massimi per chiamata e separazione del critico dall'accessorio, perché la caduta sia di un pezzo e non del sistema.
- 6E lo operiamo. Sorveglianza dello stato dei tuoi fornitori integrata con i tuoi avvisi, reperibilità con manuale degli incidenti —chi decide di cambiare percorso, quando si degrada, come si comunica—, e una prova periodica: si provoca la caduta apposta e si cronometra il ripristino. Un piano che non è mai stato eseguito non è un piano.
Cosa cambia
Quello che smetti di perdere
I grandi fornitori di modelli pubblicano una pagina di stato pubblica con storico degli incidenti e manutenzioni programmate. Il dato esiste ed è consultabile; quello che manca in quasi tutte le aziende è che quel dato entri nel proprio sistema di avvisi invece di guardarlo a mano quando qualcosa va storto.
Pagine di stato pubbliche dei fornitori (p. es. status.claude.com), consultate 2026-08
Gli accordi sui livelli di servizio dei piani enterprise dei fornitori compensano con crediti, non con continuità: recuperi una parte della fattura, non le ore di operatività ferma. La continuità te la devi montare tu, dalla tua parte.
Meccanismo · condizioni standard di SLA con crediti
La caduta smette di essere binaria. Con il degrado definito, il sistema passa da «non funziona» a «funziona peggio e lo dice», che è la differenza tra un incidente e una crisi.
Meccanismo
Budget e quota smettono di essere una risorsa comune senza padrone: ogni sistema ha la sua chiave e il suo limite, quindi un picco nell'accessorio non consuma più la capacità del critico.
Meccanismo
Cosa misuriamo: disponibilità reale per caso d'uso (non quella del fornitore), tempo di rilevamento e tempo di ripristino cronometrati in prova, % di richieste servite dal percorso secondario durante un incidente, lavoro accodato e rielaborato senza perdite, e consumo di quota per sistema rispetto al suo limite.
Cosa misuriamo
Scheda tecnica
- Lavoro che elimina
- che una caduta del fornitore di IA sia una crisi improvvisata —senza secondo percorso, senza modo degradato e senza nessuno che sappia quanto ci si può fermare— e che l'avviso arrivi da un cliente invece che dal tuo stesso sistema
- Implementazione tipica
- 4–8 settimane
- Ingresso
- i tuoi sistemi di IA in produzione, le loro dipendenze da fornitore e modello, le tue code e il tuo processo di incidenti attuale
- Uscita
- un obiettivo di ripristino concordato per caso d'uso, secondo percorso provato, degrado definito invece della schermata bianca, code con ritentativi e quota per sistema, isolamento dei guasti e una reperibilità con manuale e incidenti provati sul campo
- Compatibile con
- OpenAIAnthropicGoogle Vertex AIAzure OpenAIAmazon BedrockMistralInngestTemporalDatadogPagerDuty
- Può collegarsi con
- I tuoi fornitori di modello attuali, senza sostituirne nessunoIl tuo gateway o router di modelli, se già ce l'haiLa tua coda di messaggi e il tuo livello di ritentativiLa tua osservabilità, i tuoi alert e la tua reperibilità così come funzionano oggi
- Cosa misuriamo
- disponibilità reale per caso d'uso, non quella del fornitoretempo di rilevamento e tempo di ripristino cronometrati in prova% di richieste servite dal percorso secondario durante un incidentelavoro accodato e rielaborato senza perdite dopo una cadutaconsumo di quota per sistema rispetto al suo limite
- Adatto per
- aziende con l'IA già nel percorso critico di un'operatività reale —assistenza, fatturazione, logistica, back office— dove CIO, COO o Head of AI devono rispondere a quanto può restare fermo questo e oggi non possono
- Non adatto per
- chi ha un pilota interno senza utenti né conseguenze —lì l'alta disponibilità è spesa senza ritorno e lo diciamo prima di iniziare— né chi cerca di cambiare fornitore di modello per qualità o costo: quello è [scegliere e cambiare modello in produzione](/soluciones/elegir-y-cambiar-de-modelo-de-ia-en-produccion), un'altra funzione
Domande frequenti
Nel fatto che monitorare risponde a «cosa sta succedendo?» e disponibilità risponde a «e nel frattempo?». Il monitoraggio strumenta, misura e avvisa: è il livello di rilevamento e lo trovi sviluppato in monitorare l'IA in produzione. Senza quello non te ne accorgi, quindi è il requisito preliminare. Ma un alert non tiene in piedi il lavoro che esce: quello lo fanno il secondo percorso, il modo degradato, la coda che assorbe il colpo e l'obiettivo di ripristino concordato. Puoi avere un cruscotto impeccabile e un'operatività ferma per mezz'ora, a guardare come diventa rosso in tempo reale. La regola pratica: il monitoraggio ti dice quando agire; la disponibilità decide cosa succede se non agisci in tempo.
No, e conviene leggere cosa compra esattamente quello SLA. Gli accordi sui livelli di servizio dei fornitori compensano con crediti sulla fattura quando non rispettano l'obiettivo: recuperi soldi, non recuperi le ore in cui la tua operatività è stata ferma né i clienti che se ne sono andati. In più, l'obiettivo si misura sul servizio del fornitore, non sul tuo caso d'uso: se il tuo processo dipende da tre chiamate concatenate più un database, la tua disponibilità reale è peggiore di quella di ognuno dei pezzi presi da soli, e questo nessun contratto lo copre. Lo SLA è una garanzia commerciale; la continuità è una decisione di architettura che si prende dalla tua parte. Quello che con lo SLA facciamo sì è usarlo: i suoi obiettivi e i suoi preavvisi entrano nel calcolo di cosa ha bisogno di un secondo percorso e cosa no.
Sì, per questo non si duplica tutto. La ridondanza si applica solo dove l'obiettivo concordato con il business la giustifica, e quell'accordo è il primo passo proprio per non finire a pagare alta disponibilità sulla chat interna delle risorse umane. Nella maggior parte delle aziende con cui lavoriamo, uno o due casi d'uso giustificano il secondo percorso e il resto si risolve molto più a buon mercato: con un degrado ben definito e una coda che rielabora quando il servizio torna. Il costo che invece è fisso è quello della disciplina —chiavi e quote separate, tempi massimi, circuit breaker—, e quello si paga una volta ed evita la classe di incidente più cara che esista: quella che inizia piccola in un sistema che non conta e finisce col tirare giù quello che fattura.
Quello che abbiamo deciso prima per quel caso d'uso, ed è questa la risposta importante: si decide in anticipo, non a caldo. I quattro modi che coprono quasi tutto sono: passare al percorso secondario in automatico quando il calo di qualità è accettabile; rispondere con la parte deterministica del processo e lasciare in attesa solo ciò che ha bisogno del modello; accodare il lavoro con un tempo comunicato all'utente e rielaborarlo per intero quando il servizio torna; oppure escalare alla persona in reperibilità se il caso è critico e non ammette attesa. Ogni caso d'uso ha il suo scritto, con chi lo attiva e come si comunica. E si prova sul campo: provochiamo la caduta apposta con una periodicità concordata e cronometriamo il ripristino, perché un manuale che nessuno ha mai eseguito è un documento, non una capacità.
Lo operiamo, perché la disponibilità non è un deliverable: è una funzione che si degrada da sola se nessuno la sostiene. Aggiungi un agente e bisogna decidere se entra nel perimetro; il fornitore cambia i suoi rate limit e bisogna riaggiustare le quote; esce un modello nuovo e il percorso secondario di sei mesi fa non è più l'opzione migliore; si riorganizza la reperibilità e il manuale resta con nomi di gente che non c'è più. La parte di montaggio sono le quattro-otto settimane iniziali; quello che segue è la reperibilità, la manutenzione dei percorsi, la sorveglianza dello stato dei tuoi fornitori e la prova periodica. Se preferisci che lo operi il tuo team, lo montiamo, lo documentiamo e formiamo le persone —e lo diciamo con chiarezza nella proposta, senza legarti a noi per design. Il resto del catalogo di questa funzione sta in AI Operations.
Lo montiamo nella tua azienda?
Hai individuato il problema. Noi consegniamo la soluzione e la lasciamo misurata.