# Modelli di backup per agenti AI: come mantenere operativo il tuo agente quando un modello si guasta

> Come funzionano i modelli di backup per agenti AI, quali errori devono attivare un fallback, perché il backup si comporta diversamente e come testarlo prima di un’interruzione.

Last updated: 2026-09-28T14:00:00

Canonical URL: https://crevio.co/it/blog/ai-agent-backup-models

*Ultimo aggiornamento: settembre 2026. Pagine di stato, report sugli incidenti e documentazione verificati il 28 settembre 2026.*

**Il modello del tuo agente prima o poi si guasterà, e il modello di backup che hai configurato per subentrare non si comporterà come quello con cui hai fatto i test.** Il 28 settembre 2026, la pagina di stato dell’API Claude indicava un uptime del 99,52% nei 90 giorni precedenti. Sembra quasi la perfezione, finché non fai i calcoli: lo 0,48% di 90 giorni equivale a circa 10 ore di servizio degradato o non disponibile in un trimestre. Un modello di backup per agenti AI permette al tuo agente di continuare a funzionare durante quelle ore. Se configurato senza attenzione, però, può anche far sì che un’attività venga completata solo a metà, senza che nessuno se ne accorga, usando un modello che non è mai stato testato.

Questa guida è pensata per titolari e responsabili di aziende che eseguono agenti secondo una pianificazione o li mettono a disposizione dei clienti. Vedremo cosa può rompersi, quali errori devono attivare il passaggio a un altro modello, come gestiscono il problema i principali strumenti di routing e come verificare che il fallback funzioni prima di averne bisogno.

- **Tre tipi diversi di guasto dall’esterno sembrano uguali:** interruzioni, limiti di frequenza e modelli ritirati. Solo alcuni richiedono un modello di backup
- **Prima riprova, poi cambia modello.** Molti problemi si risolvono con un breve nuovo tentativo o usando un altro host che esegue lo stesso modello
- **Un modello di backup non è una copia equivalente.** I modelli più recenti rifiutano parametri accettati da quelli precedenti, la gestione delle chiamate agli strumenti varia e la cache del prompt non è più calda
- **I fallback costano più del previsto per ogni passaggio,** perché il backup parte con una cache fredda
- **Un fallback non testato è solo un’ipotesi.** Forza intenzionalmente un errore, esegui attività reali sul backup e registra quale modello ha risposto

## Che cos’è un modello di backup per agenti AI

Un modello di backup per agenti AI, spesso chiamato fallback LLM, è un secondo modello configurato in anticipo per subentrare quando il modello principale dell’agente non riesce a rispondere. Il passaggio è di solito automatico: un router o un gateway rileva l’errore, invia la stessa richiesta al modello successivo della lista e restituisce la risposta come se non fosse successo nulla.

È uno dei quattro livelli di protezione e dovrebbe essere il terzo a cui ricorrere, non il primo:

| Livello | Cosa fa | Risolve | Cambia il modello? |
|---|---|---|---|
| **Nuovo tentativo** | Invia di nuovo la stessa richiesta dopo una breve attesa | Picchi momentanei, timeout isolati | No |
| **Failover dell’host** | Invia la richiesta a un altro provider che esegue lo stesso modello | Guasti di un data center o di un host | No |
| **Fallback del modello** | Invia la richiesta a un modello diverso | Interruzioni complete, quote esaurite | Sì |
| **Migrazione pianificata** | Sposta intenzionalmente l’agente su un nuovo modello | Ritiri e deprecazioni | Sì, in modo permanente |

L’ordine è importante perché ogni passaggio verso il basso nella tabella cambia ulteriormente il comportamento dell’agente. Un nuovo tentativo non cambia nulla. Un modello diverso cambia quasi tutto, come vedremo nelle sezioni successive.

## Tre modi in cui il modello principale può guastarsi

### Interruzioni

È successo a tutti i principali provider e i report sugli incidenti sono pubblici. L’11 dicembre 2024, [tutti i servizi OpenAI hanno subito un grave degrado o un’interruzione](https://status.openai.com/incidents/ctrsv3lwd797) dalle 15:16 alle 19:38, ora del Pacifico: 4 ore e 22 minuti di problemi per ChatGPT, l’API e Sora. La causa era un nuovo servizio di telemetria che aveva sovraccaricato il control plane Kubernetes di OpenAI. Il bug si manifestava solo nei cluster di grandi dimensioni, quindi i test non lo avevano rilevato.

![Incidente dell’11 dicembre 2024 sulla pagina di stato di OpenAI, contrassegnato come Risolto e Interruzione completa, con 9 componenti API e 5 componenti ChatGPT interessati e barre di stato rosse e ambrate](https://crevio.co/vite/assets/openai-status-december-2024-incident-gqiohlkd.png)

Gli incidenti più brevi sono molto più comuni. Il 4 marzo 2026, OpenAI ha segnalato [30 minuti di errori API più frequenti del normale](https://status.openai.com/incidents/01KJXQDJ6P1CG5YNXKZRY2H6RX/write-up) dopo che un insieme di modifiche alla capacità, rimaste in attesa, era stato applicato contemporaneamente, rendendo indisponibili i motori di inferenza. La pagina di stato di Anthropic mostra lo stesso andamento: lunghi periodi verdi, intervallati regolarmente da brevi giornate rosse e ambrate.

![Pagina di stato di Claude con tutti i sistemi operativi e le barre di uptime degli ultimi 90 giorni: claude.ai al 99,43%, Claude Console al 99,95% e Claude API al 99,52%](https://crevio.co/vite/assets/claude-status-page-eal06oie.png)

Un’interruzione di 30 minuti passa quasi inosservata quando stai chattando. Diventa molto importante quando un’attività pianificata scatta in quella finestra, perché non c’è nessuno che possa premere di nuovo il pulsante per riprovare.

### Limiti di frequenza ed errori 429

Un errore 429 significa che il provider è operativo, ma in quel momento non può servirti. Nella maggior parte dei casi si tratta di un limite al minuto: l’API di Anthropic usa un [token bucket che si riempie continuamente](https://platform.claude.com/docs/en/api/rate-limits) e invia un’intestazione `retry-after` che indica quanti secondi attendere. Aspettare quel tempo e riprovare con lo stesso modello è la scelta corretta.

Non tutti i 429 sono però temporanei. Quando un’organizzazione Anthropic raggiunge il limite di spesa mensile, l’API restituisce un 429 **senza** intestazione `retry-after` e la documentazione è molto chiara: "Riprovare, inclusi i nuovi tentativi automatici degli SDK, non funziona finché l’accesso non viene ripristinato." L’accesso torna disponibile all’inizio del mese successivo. Un agente che tratta ogni 429 come "aspetta e riprova" continuerà a riprovare per tutta la notte contro un limite che potrebbe non azzerarsi per settimane.

### Deprecazione e ritiro dei modelli

I modelli vengono ritirati secondo una pianificazione e un modello ritirato non si degrada gradualmente. La [policy di deprecazione di Anthropic](https://platform.claude.com/docs/en/about-claude/model-deprecations) garantisce almeno 60 giorni di preavviso per i modelli rilasciati pubblicamente e specifica che "le richieste ai modelli oltre la data di ritiro falliranno". Claude Opus 4.1 è un esempio recente: gli sviluppatori sono stati avvisati il 5 giugno 2026 e il modello è stato ritirato il 5 agosto 2026.

![Pagina della documentazione di Claude Platform sulla deprecazione dei modelli, con le fasi del ciclo di vita Attivo, Legacy, Deprecato e Ritirato e un avviso che i modelli deprecati sono probabilmente meno affidabili di quelli attivi](https://crevio.co/vite/assets/claude-model-deprecations-gt44ujck.png)

La [pagina di deprecazione di OpenAI](https://developers.openai.com/api/docs/deprecations) garantisce ai modelli disponibili generalmente almeno sei mesi di preavviso, ma i modelli in anteprima "potrebbero essere ritirati con un preavviso molto più breve, ad esempio di 2 settimane". A giugno 2026 ha annunciato che gli snapshot GPT-5 e o3 sarebbero stati disattivati l’11 dicembre 2026. Un modello di backup non risolve un ritiro: lo nasconde soltanto fino all’arrivo della data di ritiro del backup stesso.

### Il guasto che nessun fallback rileva

Il guasto più costoso è quello che non genera mai un errore. Nel 2025, Anthropic ha pubblicato [un postmortem su tre bug dell’infrastruttura](https://www.anthropic.com/engineering/a-postmortem-of-three-recent-issues) che avevano degradato le risposte di Claude per settimane. Nell’ora peggiore, uno di questi problemi aveva coinvolto il 16% delle richieste a Sonnet 4. Uno dei motivi per cui ci è voluto tanto a individuarlo è che "Claude spesso recupera bene dagli errori isolati", mascherando così il problema.

Nessuna catena di fallback si attiva in caso di una risposta peggiore, perché una risposta peggiore restituisce comunque un codice 200. Per questo servono [controlli a campione sui risultati prodotti dall’agente](/it/blog/human-in-the-loop-ai-agents), non il routing.

## Quali guasti devono attivare un modello di backup per agenti AI

Leggi l’errore prima di reagire. Lo stesso messaggio "il modello non ha funzionato" può significare aspetta cinque secondi, cambia subito modello oppure correggi la tua richiesta.

![Cinque errori dei provider e la risposta corretta a ciascuno: attendere e riprovare in caso di 429 con retry-after, passare al backup in caso di 429 senza retry-after, riprovare, cambiare host e poi modello in caso di 5xx o timeout, correggere la richiesta in caso di 400 e promuovere il sostituto prima della data di ritiro](https://crevio.co/vite/assets/which-failures-need-a-backup-model-mvzdhotu.svg)

Due righe meritano un’analisi più attenta:

- **Errori 5xx, sovraccarico e timeout.** Il [riferimento agli errori di Anthropic](https://platform.claude.com/docs/en/api/errors) elenca un `overloaded_error` 529 per il traffico elevato che coinvolge tutti gli utenti; gli SDK eseguono già due nuovi tentativi per gli errori temporanei, con backoff esponenziale. Un tentativo aggiuntivo va bene. Cinque sono il modo migliore per trasformare un problema di 30 secondi in un blocco di 10 minuti
- **Errori 400.** Un parametro errato o una richiesta malformata fallirà anche sul backup, spesso per lo stesso motivo. L’eccezione è rappresentata dai prompt troppo lunghi: alcuni router li inviano invece a un modello con una finestra di contesto più ampia. In questo caso il fallback è utile

## Come funzionano le catene di fallback e il routing

Raramente devi creare da solo la logica di fallback. Se ne occupa un livello di routing tra il tuo agente e i provider. Quattro strumenti sono particolarmente comuni:

| Strumento | Come configuri il backup | Cosa lo attiva | Come vedi quale modello ha risposto |
|---|---|---|---|
| **OpenRouter** | Un array `models` in ordine di priorità | Indisponibilità, limiti di frequenza, errori di lunghezza del contesto, flag di moderazione | Il campo `model` nella risposta |
| **LiteLLM** | `fallbacks`, più fallback separati per la finestra di contesto e la policy sui contenuti | Limiti di frequenza ed errori del server, con cooldown dopo errori ripetuti | Log del proxy e callback |
| **Vercel AI Gateway** | Un array `models` combinato con un provider `order` | Qualsiasi errore di tutti i provider per un modello | Un elenco `modelAttempts` nei metadati del provider |
| **Cloudflare AI Gateway** | Un elenco di passaggi sull’endpoint Universal | Errori e timeout delle richieste | L’intestazione di risposta `cf-aig-step` |

I [fallback dei modelli di OpenRouter](https://openrouter.ai/docs/guides/routing/model-fallbacks) sono i più semplici da visualizzare: passi un elenco di ID modello e "se il primo modello restituisce un errore, OpenRouter proverà automaticamente il modello successivo nell’elenco". Le richieste vengono fatturate al prezzo del modello che ha risposto alla fine. Separatamente, il suo [routing dei provider](https://openrouter.ai/docs/guides/routing/provider-selection) gestisce il failover dell’host per lo stesso modello. Per impostazione predefinita, preferisce i provider che "non hanno registrato interruzioni significative negli ultimi 30 secondi" e `allow_fallbacks` rimane attivo finché non lo disattivi.

![Pagina della documentazione di OpenRouter sui fallback dei modelli, che spiega come il parametro models provi automaticamente altri modelli se i provider del modello principale sono indisponibili, soggetti a limiti di frequenza o rifiutano di rispondere](https://crevio.co/vite/assets/openrouter-model-fallbacks-docs-k3qy0sqx.png)

Le [impostazioni di affidabilità di LiteLLM](https://docs.litellm.ai/docs/proxy/reliability) suddividono il problema in modo più dettagliato. I normali `fallbacks` gestiscono limiti di frequenza ed errori del server, `context_window_fallbacks` invia un prompt troppo grande a un modello più capiente e `content_policy_fallbacks` intercetta gli errori relativi alle policy sui contenuti. `allowed_fails` e `cooldown_time` escludono temporaneamente dalla rotazione un modello che sta fallendo, così un provider in difficoltà non viene sollecitato a ogni richiesta.

I [fallback dei modelli di Vercel AI Gateway](https://vercel.com/docs/ai-gateway/models-and-providers/model-fallbacks) combinano entrambi i livelli: prova tutti i provider consentiti per il modello principale, poi passa al modello successivo nell’array `models` e registra ogni tentativo. I [fallback di Cloudflare AI Gateway](https://developers.cloudflare.com/ai-gateway/configuration/fallbacks/) funzionano sul suo endpoint Universal e indicano in un’intestazione da dove proviene la risposta: `cf-aig-step: 0` significa che ha risposto il modello principale, `1` indica che ha risposto il primo fallback.

A tutti e quattro si applica una precauzione. **Anche il gateway è una dipendenza.** La rete di Cloudflare ha subito una grave interruzione il [18 novembre 2025](https://blog.cloudflare.com/18-november-2025-outage/), dalle 11:20 alle 17:06 UTC, dopo che un file di configurazione errato si era propagato al suo interno. Una catena di fallback ti protegge dal guasto di un provider di modelli. Non può proteggerti dal livello che esegue la catena.

## Perché un modello di backup per agenti AI si comporta diversamente

Un fallback che restituisce una risposta non ha necessariamente portato a termine il lavoro. In questo gli agenti sono più fragili dei chatbot, perché al momento del passaggio stanno eseguendo un’attività in più fasi e portano con sé una lunga cronologia di chiamate agli strumenti che il nuovo modello deve riprendere.

![Cosa cambia quando un agente passa da un modello all’altro: usare lo stesso modello su un altro host mantiene il comportamento del prompt, il formato delle chiamate agli strumenti, i parametri e la finestra di contesto; un modello più recente dello stesso provider o il modello di un altro provider cambia la maggior parte di questi elementi, e ogni passaggio fa perdere la cache calda del prompt](https://crevio.co/vite/assets/what-changes-when-an-agent-switches-models-nxjdqm6x.svg)

### Parametri accettati da un modello e rifiutati da un altro

Questo problema si presenta anche all’interno dello stesso provider. Secondo le [note sulla deprecazione di Anthropic](https://platform.claude.com/docs/en/about-claude/model-deprecations) e il suo [riferimento agli errori](https://platform.claude.com/docs/en/api/errors):

- Impostare `temperature`, `top_p` o `top_k` su un valore diverso da quello predefinito restituisce un errore 400 su Claude Opus 4.7 e versioni successive
- Forzare uno strumento specifico con `tool_choice` restituisce un errore 400 su Claude Opus 5.5, Sonnet 5.5 e Fable 5.1
- Precompilare l’inizio della risposta dell’assistente restituisce un errore 400 su Claude 4.6 e sui modelli successivi

Una catena che passa da un modello precedente a uno più recente e "migliore" può quindi fallire immediatamente con un errore che il modello principale non aveva mai prodotto. L’opzione [`require_parameters` di OpenRouter](https://openrouter.ai/docs/guides/routing/provider-selection) esiste in parte proprio per questo: instrada le richieste solo verso provider che supportano ogni parametro inviato.

### Chiamate agli strumenti e prompt

Provider diversi si aspettano strumenti, risultati e ragionamenti in formati diversi. Un fallback tra provider dipende quindi dalla capacità del gateway di tradurre correttamente la conversazione. Anche quando il formato viene mantenuto, il backup non è il modello su cui hai messo a punto le istruzioni. Potrebbe chiamare gli strumenti in un ordine diverso, fermarsi prima o interpretare "sii conciso" come "salta la verifica". Alcuni dati di ragionamento non vengono trasferiti affatto: Anthropic osserva che un blocco di thinking "proveniente da un modello che il modello di destinazione non è in grado di leggere viene eliminato".

### Finestre di contesto

Se il backup legge meno testo del modello principale, una sessione lunga dell’agente potrebbe essere troppo grande per lui nel momento in cui subentra. Per questo OpenRouter indica gli errori relativi alla lunghezza del contesto tra le cause di fallback e LiteLLM dedica loro un elenco di fallback separato. Inserisci nella catena un backup con una finestra di contesto almeno pari a quella del modello principale oppure fai condensare all’agente la cronologia più vecchia prima del passaggio.

## Quanto costano i fallback

Un modello di backup modifica la spesa in tre modi, nessuno dei quali emerge da una tabella comparativa dei prezzi.

**La cache calda scompare.** Il prompt caching contribuisce in modo significativo a mantenere convenienti gli agenti: a ogni passaggio vengono reinviati istruzioni, definizioni degli strumenti e cronologia, fatturati per lo più alla tariffa della cache. Le cache appartengono a un modello specifico su un provider specifico. Per questo OpenRouter usa lo [sticky routing](https://openrouter.ai/docs/guides/best-practices/prompt-caching) "per instradare le richieste successive verso lo stesso endpoint del provider dopo una richiesta con cache". Se cambi modello, il passaggio successivo viene fatturato a prezzo pieno. Al [prezzo di listino di Claude Sonnet 5.5](https://platform.claude.com/docs/en/about-claude/pricing) di 2,00 $ per milione di token di input e 0,20 $ con cache, una cronologia di 50.000 token costa circa 0,01 $ se reinviata dalla cache e circa 0,10 $ senza cache. Dieci volte tanto per ogni passaggio, finché non si scalda la cache del backup.

**Paghi ciò che ha risposto, con i suoi token.** OpenRouter fattura il modello che ha risposto alla fine. Un fallback verso un modello più costoso quindi aumenta la spesa; anche un backup più economico che richiede più passaggi per completare il lavoro può costare di più. Inoltre, i conteggi dei token non sono direttamente confrontabili: la [pagina dei prezzi di Anthropic](https://platform.claude.com/docs/en/about-claude/pricing) indica che i modelli Claude 4.7 e successivi usano un tokenizer più recente, che produce circa il 30% di token in più a parità di testo.

**Anche i nuovi tentativi vengono fatturati.** Una richiesta che fallisce a metà di uno stream ha spesso già prodotto token a pagamento e ogni nuovo tentativo reinvia l’intero contesto. Abbiamo spiegato come si accumulano questi costi nella guida ai [costi di esecuzione degli agenti AI](/it/blog/ai-agent-running-costs): le esecuzioni fallite e i loop possono diventare una coda lunga che supera la media.

Niente di tutto questo è un argomento contro i backup. È un argomento a favore del loro uso come backup, lasciando che i nuovi tentativi e il failover dell’host assorbano gli errori quotidiani, così il costoso passaggio a un altro modello avviene solo durante le vere interruzioni.

## Testa il fallback prima di averne bisogno

La maggior parte delle catene di fallback viene utilizzata per la prima volta durante un incidente: il momento peggiore per scoprire che il backup non sa chiamare i tuoi strumenti. Una breve esercitazione una volta a trimestre e dopo ogni modifica al modello permette di individuare la maggior parte dei problemi:

1. **Forza il guasto.** Indirizza il modello principale verso un ID modello inesistente oppure usa l’interruttore di test del router. LiteLLM offre `mock_testing_fallbacks=True` nel suo SDK e, per il proxy, consiglia di generare un errore reale del provider in un ambiente non di produzione
2. **Esegui attività reali, non un prompt "ciao mondo".** Scegli tre o quattro attività effettive del tuo agente, inclusa un’esecuzione lunga e ricca di chiamate agli strumenti, e lascia che vengano completate interamente dal backup
3. **Confronta i risultati.** Ha chiamato gli stessi strumenti, si è fermato nello stesso punto e ha rispettato le regole di formattazione? Leggi le trascrizioni, non solo la risposta finale
4. **Verifica quale modello ha risposto.** Controlla il campo di risposta `model`, `modelAttempts` o l’intestazione `cf-aig-step`. Un test in cui ha risposto silenziosamente il modello principale non dimostra nulla
5. **Configura avvisi sui fallback.** Un backup che si attiva ogni giorno non è più un backup. È il tuo modello reale, non testato a quel volume, e devi saperlo
6. **Segna le date di ritiro in calendario.** Controlla le pagine di deprecazione sia del modello principale sia del backup e passa al sostituto con largo anticipo rispetto a entrambe le date

Per le attività pianificate, affianca a questo processo un piano per le esecuzioni che falliscono comunque. La nostra guida alla [pianificazione di attività ricorrenti per agenti AI](/it/blog/schedule-recurring-ai-agent-tasks) spiega come dovrebbe apparire un buon errore: un risultato parziale, un messaggio chiaro e un’attività che si interrompe da sola invece di riprovare all’infinito.

## Come l’agente di Crevio gestisce i guasti dei modelli

[Crevio](https://crevio.co/) è un AI business builder: descrivi cosa vuoi vendere e il suo agente crea, lancia e gestisce il lavoro necessario. Crevio sceglie ed esegue i modelli alla base dell’agente, quindi non devi gestire account dei provider, chiavi o versioni dei modelli. Ecco cosa succede quando un modello si comporta male, spiegato con chiarezza, incluso ciò che Crevio non fa.

**Cosa fa oggi:**

- **Ripete automaticamente la richiesta allo stesso modello.** Quando una chiamata al modello fallisce per sovraccarico, limite di frequenza, errore del server, timeout o risposta interrotta a metà dello stream, l’agente riprova fino a tre volte, aspettando ogni volta un po’ più a lungo, fino a circa 2, 4 e 8 secondi. Gli errori che un nuovo tentativo non può risolvere, come una richiesta malformata, non vengono ripetuti
- **Evita l’host appena guasto.** Per i modelli che possono essere forniti da più host, un nuovo tentativo dopo un errore dell’host esclude quello che lo ha appena prodotto
- **Condensa le conversazioni lunghe.** Se una conversazione supera ciò che il modello è in grado di leggere, l’agente riassume la cronologia precedente e riprova una volta, invece di fermarsi
- **Controlla l’elenco dei modelli a ogni release.** Ogni volta che Crevio pubblica un aggiornamento, verifica che tutti i modelli da cui l’agente dipende siano ancora disponibili; se uno è scomparso, la release viene contrassegnata come fallita

![Modulo per una nuova attività di Crevio per un riepilogo quotidiano delle vendite del mattino, con istruzioni per indicare quale origine dati non è stata raggiunta, impostato per ripetersi ogni giorno e con Notifica tramite configurato su notifica nell’app ed e-mail](https://crevio.co/vite/assets/crevio-task-failure-notifications-cq6okyoe.png)

**Cosa succede se continua a fallire:** un’esecuzione pianificata che fallisce viene segnalata attraverso i canali indicati nell’impostazione **Notifica tramite**, insieme a ciò che è stato completato e a cosa è andato storto. Per impostazione predefinita, un’attività ricorrente si disattiva dopo tre esecuzioni fallite consecutive e te lo comunica, invece di fallire ogni mattina senza che nessuno se ne accorga. In una chat attiva, una risposta che esaurisce i nuovi tentativi semplicemente si interrompe e puoi inviare di nuovo il messaggio.

**Cosa non fa ancora:** l’agente di Crevio non passa automaticamente a un modello diverso durante un’attività se il modello principale è indisponibile. Oggi la protezione consiste nei nuovi tentativi e nel failover dell’host sullo stesso modello. Inoltre non puoi scegliere il modello dell’agente né collegare una chiave del tuo provider. Se ti serve una catena di fallback personalizzata tra più provider, uno strumento di routing della tabella precedente, inserito nel tuo stack, ti offre questo controllo.

[Crevio](https://crevio.co/) è disponibile gratuitamente e il piano Starter include 20 crediti AI al mese.

## Domande frequenti

### Mi serve un modello di backup se uso già un gateway AI?

Il gateway è il luogo in cui configuri il backup, non è un backup di per sé. Alcuni gateway eseguono autonomamente nuovi tentativi o passano da un host all’altro per lo stesso modello, ma il fallback del modello si verifica solo se ne indichi uno. Aggiungono inoltre una dipendenza propria, quindi controlla come si è comportato il tuo gateway durante gli incidenti passati.

### Il modello di backup per un agente AI dovrebbe provenire da un provider diverso?

Per le interruzioni, sì: un backup dello stesso provider spesso diventa indisponibile nello stesso incidente. Per i limiti di frequenza, può bastare un secondo modello dello stesso provider, perché i limiti sono solitamente impostati per modello. Il compromesso riguarda la compatibilità: più il backup è diverso dal modello principale, più dovrai testare prompt, chiamate agli strumenti e parametri.

### Con quale frequenza devo testare il mio fallback LLM?

Esegui un test dopo ogni modifica al modello principale, al backup, alle istruzioni o agli strumenti dell’agente e, negli altri casi, almeno una volta a trimestre. Controlla inoltre le date di deprecazione di entrambi i modelli ogni volta, perché un backup ritirato fallisce esattamente quando ti serve.

## Un backup mai utilizzato è solo un’ipotesi

Interruzioni, limiti di frequenza e ritiri sono ormai eventi ordinari e un buon modello di backup per agenti AI può trasformare un report mattutino saltato in un report solo un po’ più lento. Il valore, però, sta nell’ordine con cui applichi le contromisure: prima riprova, poi cambia host, quindi cambia modello, e usa solo un backup che hai già visto completare attività reali. Se non l’hai testato, non hai un fallback. Hai solo una seconda cosa che può guastarsi.

## Articoli correlati

- [Costi di esecuzione degli agenti AI: quanto costa davvero un agente al mese](/it/blog/ai-agent-running-costs)
- [Come pianificare attività ricorrenti per agenti AI che funzionano senza di te](/it/blog/schedule-recurring-ai-agent-tasks)
- [Agenti AI con supervisione umana: cosa approvare e cosa lasciare eseguire](/it/blog/human-in-the-loop-ai-agents)
- [Agenti AI per le aziende: cosa implementare per primo, reparto per reparto](/it/blog/ai-agents-for-business)