Salta al contenuto
AI Routing

Fallback AI: garantire continuità quando un provider cade

Disservizi, limiti di frequenza e degradi di latenza sono normali. Come progettare fallback tra modelli per non fermare il lavoro delle persone.

5 min

Quando un'azienda dipende da un solo fornitore di AI, un disservizio del fornitore diventa un disservizio dell'azienda. Con un pool di modelli, diventa un evento registrato e nulla più.

Tipi di guasto da gestire

Indisponibilità totale, limiti di frequenza superati, latenza fuori soglia, risposte vuote o troncate, esaurimento del credito presso il fornitore.

Catena di fallback

Per ogni categoria di compito serve un modello primario e almeno un'alternativa equivalente, con soglie esplicite di attivazione e un limite ai tentativi per non moltiplicare il costo.

Verificare che funzioni

Un fallback mai testato è un'ipotesi. Prove periodiche con disabilitazione controllata del primario sono l'unico modo per averne conferma.

Domande frequenti

Il fallback aumenta i costi?+

Marginalmente, perché si attiva solo in caso di guasto. Il costo di non averlo è il fermo operativo.

L'utente si accorge del cambio di modello?+

Non nel flusso di lavoro. L'evento resta però registrato e visibile agli amministratori nel dettaglio dei consumi.

Quanti tentativi impostare prima di rinunciare?+

Due o tre al massimo: oltre, il tempo di attesa percepito supera il beneficio e il costo cresce senza risultato.

Continua a leggere

Vuoi vedere Artiplane sui vostri casi d'uso?

Una demo di 30 minuti sul vostro scenario reale: routing, budget per area e tracciamento delle interazioni.

Richiedi una demo