Come progettare il fallback manuale di un workflow AI

Il modello non risponde. La richiesta, invece, è già arrivata.

Il workflow prova ancora, poi ancora. Nel frattempo una persona apre il foglio vecchio, un'altra prepara una risposta a mano e nessuno sa se l'automazione abbia già scritto sul sistema finale.

Un fallback manuale serve a evitare questo doppio lavoro. Definisce quale servizio minimo resta disponibile, quando scatta, chi prende la coda, quali azioni sono vietate e come si torna al flusso normale senza perdere o duplicare casi.

Il fallback riduce la promessa

La modalità degradata non deve fingere che tutto funzioni.

Google SRE descrive la graceful degradation come un modo per ridurre lavoro o qualità della risposta e continuare a servire qualcosa di utile. Per un workflow AI aziendale può significare consegnare una bozza senza classificazione automatica, accodare la richiesta per una persona oppure restituire un esito esplicito con i campi mancanti.

Scrivi tre livelli:

Livello	Cosa consegna	Cosa ferma
Normale	output completo con controlli	casi fuori perimetro
Degradato	output minimo verificabile	azioni non essenziali o ad alto impatto
Stop	ricevuta e istruzione umana	ogni scrittura o decisione automatica

Se il livello degradato conserva tutto lo scope normale, non è un fallback. È lo stesso workflow con meno prove.

Definisci il servizio minimo

Parti dalla domanda: cosa deve ricevere la persona per non perdere il caso?

Per una richiesta interna, il minimo può essere un ID, il timestamp, i riferimenti agli input, lo stato e il prossimo owner. Per una bozza editoriale può essere il testo estratto senza riscrittura, accompagnato da review_required. Per un'azione su un account esterno, il minimo può essere soltanto una ricevuta di stop.

La SOP del workflow AI descrive il percorso normale. Aggiungi una tabella separata per il percorso degradato:

fallback_id: manual-review-v2
minimum_service:
  - request_receipt
  - source_references
  - explicit_status
forbidden_actions:
  - external_write
  - automatic_approval
  - silent_retry
queue_owner: operations-desk
exit_criteria: dependency_green_and_queue_reconciled

Evita il file piano B definitivo.xlsx. Il fallback è parte del servizio e va versionato insieme al flusso normale.

Classifica il guasto prima del trigger

L'AI è giù raccoglie casi diversi.

Il modello può non rispondere. Il retrieval può restituire zero fonti. Un connettore può andare in timeout dopo una scrittura. La policy può bloccare il caso. La qualità può scendere sotto soglia pur con tutti i sistemi disponibili.

Usa classi che portano a un'azione:

• dependency_unavailable, nessuna risposta affidabile
• input_invalid, richiesta incompleta o fuori schema
• quality_below_gate, output presente ma non utilizzabile
• policy_block, azione non autorizzata
• effect_unknown, chiamata partita senza ricevuta conclusiva

I primi tre casi possono avere fallback diversi. Effect_unknown richiede riconciliazione. Ripetere subito può creare un duplicato.

Il registro degli incidenti AI conserva l'anomalia e le azioni successive. Il contratto di fallback decide cosa fare nel minuto in cui il servizio cambia stato.

Scegli trigger che puoi osservare

Un trigger come quando il sistema va male non può essere testato.

Collega il passaggio a segnali verificabili:

• timeout oltre la soglia concordata
• errori ripetuti oltre il budget di retry
• fonte obbligatoria assente
• controllo di qualità rosso
• ricevuta remota mancante
• comando manuale di un ruolo autorizzato

Scrivi anche il livello. Un problema su una funzione accessoria può togliere quella funzione. Un dubbio sull'effetto di una scrittura può fermare l'intero caso.

Google SRE avverte che i retry possono amplificare un guasto. Il fallback non deve aggiungere una seconda tempesta di chiamate. Ferma la ripetizione, conserva la richiesta e rende visibile il passaggio di stato.

Costruisci una coda che non perde identità

La persona non deve ricevere una cartella di screenshot.

Ogni voce conserva:

Campo	Perché serve
request_id	impedisce che lo stesso caso sembri nuovo
received_at	ordina e misura l'attesa
failure_class	indica il percorso ammesso
last_known_state	mostra fino a dove è arrivato il workflow
effect_status	distingue none, confirmed e unknown
source_refs	permette il controllo senza copiare dati inutili
owner	assegna una persona o un ruolo
next_action	evita interpretazioni a memoria

Non copiare prompt completi, segreti o dati personali nella coda. Conserva riferimenti e accessi coerenti con la policy.

Limita l'autorità manuale

Il passaggio a una persona non estende il perimetro.

La matrice di approvazione per workflow AI definisce chi può approvare cosa. Il fallback la riusa. Se l'automazione poteva preparare una bozza ma non inviarla, il desk manuale non ottiene il permesso di invio per il solo fatto che il modello è fermo.

Tre frasi devono essere leggibili nella scheda:

può fare:
deve chiedere:
non può fare:

Il limite protegge anche il reviewer. Durante un guasto cresce la pressione a chiudere. Una regola scritta evita che urgenza e autorità diventino la stessa cosa.

Progetta l'handover

La notifica serve intervento umano scarica il problema senza consegnarlo.

Un handover utile contiene motivo, stato, prove, opzioni ammesse e tempo utile. La persona deve capire se può completare, chiedere un dato oppure fermare il caso.

Esempio:

richiesta: req-204
stato: review_required
motivo: fonte obbligatoria non raggiungibile
effetti esterni: nessuno avviato
puoi: verificare la fonte o chiedere integrazione
non puoi: pubblicare la bozza
scadenza operativa: 16:30

Il messaggio evita due ambiguità: cosa è già successo e cosa resta autorizzato.

Rientra soltanto dopo la riconciliazione

Dipendenza verde non significa coda pulita.

Prima di riattivare il flusso normale:

1. verifica la causa e il segnale di recupero
2. congela l'arrivo di duplicati durante il passaggio
3. riconcilia ogni request_id col sistema finale
4. separa casi completati, da riprendere e con effetto sconosciuto
5. riapri con un campione controllato

Un caso completato a mano non deve ripartire da zero. Un caso con effect_unknown non deve essere ripetuto finché il sistema finale non conferma presenza o assenza dell'azione.

Prova il percorso quando tutto è verde

Google SRE segnala un rischio semplice: il codice usato raramente tende a non funzionare quando serve. Lo stesso vale per il foglio, il canale e i permessi del fallback.

Esegui una prova controllata. Scollega una dipendenza in ambiente sicuro, inserisci richieste sintetiche e verifica trigger, coda, handover e rientro. Controlla anche il caso scomodo: una ricevuta mancante dopo una chiamata.

La prova non deve toccare dati o account reali senza autorizzazione. Può usare un ambiente di test e side effect fittizi.

Un esempio fittizio

Un workflow classifica richieste e prepara una bozza. Il retrieval smette di rispondere alle 10:12. Il trigger scatta dopo due errori controllati.

Il sistema assegna un ID alle nuove richieste, conserva i riferimenti agli allegati e manda al desk una coda senza testo generato. Lo stato diventa source_unavailable. Nessuna bozza viene inviata.

Alle 10:41 la dipendenza torna verde. Il team prova tre casi sintetici, riconcilia 18 ID e trova una richiesta già chiusa a mano. Quella voce viene marcata completed_manual e non riparte.

I numeri descrivono il caso. Non sono dati MAIKER HUB.

Misura il fallback

Conta ingressi in modalità degradata, casi persi, duplicati, tempo di presa in carico, quota con effetto sconosciuto e rientri falliti. Se la coda cresce più velocemente della capacità manuale, il servizio minimo va ridotto o fermato.

Per la pagina SEO, osserva impressioni, query non-brand e invii form aggregati. L'impatto richiede almeno 28 giorni comparabili dopo un eventuale rilascio.

Gli errori che rompono il piano B

Il primo è copiare l'intero workflow a mano. Il team eredita la stessa complessità senza controlli automatici.

Il secondo è usare un canale senza owner. Tutti vedono la coda e nessuno la prende.

Il terzo è riprovare una scrittura con esito sconosciuto. Il duplicato nasce nel tentativo di recupero.

Il quarto è riattivare appena torna il verde tecnico. Restano casi chiusi a mano e richieste sospese.

Il quinto è non provare mai il fallback. Il giorno del guasto manca proprio il permesso necessario al desk.

Think, Build, Enable applicato al fallback

Think: definisci il servizio minimo, le classi di guasto e le azioni che restano vietate.

Build: crea trigger, coda, handover, riconciliazione e criteri di rientro. Provali con casi sintetici.

Enable: assegna owner e backup, forma il desk e misura ogni passaggio in modalità degradata.

Il fallback non salva l'automazione. Salva il lavoro che l'automazione doveva consegnare.