Come dismettere un workflow AI in azienda

Venerdì, 18:07. Il job schedulato risulta spento. Lunedì mattina, però, un foglio continua a importare le sue bozze e 2 persone aspettano ancora la notifica di approvazione.

Scenario fittizio. Il dettaglio conta perché mostra il problema: spegnere il job non ha chiuso il workflow.

Per dismettere un workflow AI devi fermare nuovi input, trovare le dipendenze, assegnare un fallback, decidere cosa succede a dati e accessi, avvisare chi lo usa e provare che nessuna azione residua continua a partire. Il risultato è un pacchetto di uscita verificato, non una cartella chiamata old.

Dismettere è una transizione

Un workflow può diventare inutile per motivi diversi. Il processo è cambiato. Il provider non è più ammesso. Le prestazioni sono uscite dalla tolleranza. Il costo supera il valore osservato. Oppure il caso d'uso è stato assorbito da un altro flusso.

Il motivo cambia il piano. Se il workflow è solo ridondante, puoi preparare una migrazione ordinata. Se produce effetti fuori limite, prima lo porti in uno stato sicuro. Se dipende da un servizio di terze parti che non risponde, attivi il fallback già deciso.

NIST AI RMF Govern 1.7 tratta la dismissione come un processo da eseguire senza aumentare il rischio. Il profilo NIST per la generative AI porta la supervisione fino al decommissioning e propone di usare la tolleranza al rischio quando un modello opera fuori dai limiti definiti. Sono riferimenti di governo. Non dicono quale pulsante premere nel tuo stack.

Apri una scheda di uscita

La decisione deve avere un oggetto preciso. Spegniamo l'AI per il supporto è troppo largo. Serve l'identificatore del workflow, la versione, l'ambiente, il process owner e il technical owner.

Una scheda minima può partire così:

workflow_id: WF-SUPPORT-014
version: 6
state: retirement_planned
reason: source_contract_ended
decision_owner: support_operations
technical_owner: automation_team
new_input_cutoff: 2026-09-04T17:00:00+02:00
fallback: manual_draft_queue
closure_evidence_due: 2026-09-08T12:00:00+02:00

Date e nomi sono fittizi. La struttura separa chi decide dal team che esegue il piano. Evita anche la frase più pericolosa di questa fase: pensavo lo avessi spento tu.

Collega la scheda all'inventario e alla roadmap per integrare l'AI in azienda. L'inventario cambia stato. La roadmap decide se il bisogno resta, viene trasferito o si chiude.

Mappa le dipendenze in 4 direzioni

Parti da ciò che entra. Poi guarda cosa esce, cosa può cambiare e chi aspetta un risultato.

Direzione	Domanda	Prova utile
input	quali fonti, form, cartelle o eventi avviano il workflow?	trigger, schedule, webhook, regola di polling
output	dove finiscono bozze, record, file o notifiche?	coda, tabella, cartella, canale
azioni	cosa può creare, inviare, modificare o approvare?	elenco azioni consentite e negate
persone	chi usa, controlla o aspetta l'output?	owner, reviewer, destinatari, supporto

La mappa deve includere anche i consumatori silenziosi. Un foglio che legge una tabella ogni ora non compare nel diagramma del workflow, ma si rompe quando la tabella smette di aggiornarsi. Stesso discorso per dashboard, report, alert e automazioni a valle.

Usa ID e riferimenti. Non copiare token, prompt completi o record personali nel pacchetto di uscita.

Definisci cutoff e fallback

Il cutoff chiude l'ingresso di nuovo lavoro. Il fallback dice come gestire ciò che arriva dopo.

Scrivi almeno 3 momenti:

1. ultimo input accettato dal vecchio workflow,
2. ultimo output che può ancora uscire,
3. momento in cui il fallback diventa l'unico percorso ammesso.

Un fallback può essere manuale, un workflow sostitutivo oppure la sospensione dichiarata del servizio. Non deve per forza replicare tutte le funzioni. Deve coprire il bisogno minimo senza introdurre un'azione più rischiosa.

Govern 6.2 del NIST AI RMF richiama processi di contingenza per dipendenze AI di terze parti ad alto rischio. Traduzione operativa: non aspettare il guasto del provider per decidere dove vanno le richieste.

Qui tocca essere noiosi. Prova il fallback con 1 input ammesso, 1 input incompleto e 1 caso che deve fermarsi. Se il percorso manuale esiste solo in una slide, non è un fallback.

Separa dati, accessi e prove

Dati e accessi non sono lo stesso lavoro.

Il data owner decide cosa va conservato, trasferito, anonimizzato o eliminato secondo policy, contratto e norme applicabili. L'owner degli accessi decide quando revocare account, secret, ruolo, integrazione o autorizzazione. Il process owner conferma che il servizio non dipende più dal vecchio flusso.

Il pacchetto registra le decisioni senza contenere i segreti:

Oggetto	Decisione	Owner	Evidenza di chiusura
input storici	retention secondo policy applicabile	data owner	ticket o registro approvato
output ancora in coda	completare o annullare per ID	process owner	coda a zero o lista eccezioni
credenziale provider	revoca dopo il cutoff	access owner	ID ricevuta, non il secret
schedule	disattivazione dopo l'ultimo run	technical owner	stato e timestamp
dashboard a valle	collegamento al nuovo feed	reporting owner	controllo su dato aggiornato

Non inventare una retention universale. Non cancellare dati perché il workflow è spento. E non lasciare credenziali attive per sicurezza senza owner, scadenza e motivo.

Spegni a strati

Un ordine prudente evita che il workflow riceva lavoro mentre stai chiudendo le uscite.

Prima blocchi nuovi input o li mandi al fallback. Poi svuoti o classifichi il lavoro in corso. Disabiliti le azioni esterne. Fermi schedule e trigger. Revoca e archiviazione arrivano secondo il piano degli owner competenti.

La sequenza cambia in base al rischio. Un workflow che prepara bozze interne non ha lo stesso stop path di uno che invia messaggi o modifica record. Se un'azione è difficile da annullare, mettila tra le prime cose da neutralizzare.

La checklist per verificare gli output AI aiuta sul lavoro rimasto in coda. Ogni output aperto riceve un esito: completato, trasferito, respinto oppure congelato con owner e motivo.

Prova anche l'assenza

La verifica finale non cerca soltanto un messaggio success. Cerca l'assenza di nuove azioni.

Fai un controllo dopo il cutoff e uno dopo il periodo massimo in cui un trigger ritardato potrebbe ancora partire. Guarda schedule, code, destinazioni e alert. Se il workflow aveva retry, controlla anche quelli.

Un evidence pack utile contiene:

• baseline dell'ultima versione attiva,
• ID dell'ultima richiesta accettata,
• ID e stato degli item rimasti aperti,
• timestamp di stop per trigger e azioni,
• esito del test del fallback,
• ricevute di revoca o trasferimento per riferimento,
• approvazione finale del process owner.

Zero screenshot senza contesto. Ogni prova deve dire cosa mostra, a quale componente si riferisce e quando è stata raccolta.

Un esempio completo

Scenario fittizio. WF-KB-009 legge articoli approvati della knowledge base e prepara una bozza di risposta per il team supporto. Non invia messaggi. Il provider di ricerca verrà rimosso il 12 settembre.

Il team fissa il cutoff alle 17:30 del 10 settembre. Da quel momento le nuove richieste entrano nella coda manuale. Restano 7 bozze aperte: 5 vengono riviste, 1 è respinta per fonte mancante, 1 viene trasferita con il relativo source ID.

La mappa trova 3 dipendenze. Una dashboard conta le bozze accettate. Un alert segnala code ferme. Un foglio importa l'esito ogni 2 ore. Il piano collega dashboard e foglio alla nuova coda, poi disattiva l'alert del vecchio flusso.

Il 12 settembre il technical owner ferma schedule e trigger. L'access owner revoca la credenziale del provider e registra la ricevuta. Il data owner applica la policy già approvata agli input storici. Il 14 settembre un test invia 3 richieste: tutte finiscono nella coda manuale, nessuna appare nella vecchia destinazione.

Stato finale: retired. Non offline, non forse spento.

Se il workflow fosse un assistente conversazionale, partiresti dai requisiti del chatbot aziendale: fonti, casi da rifiutare, percorso verso una persona e azioni ammesse devono avere una destinazione anche dopo lo spegnimento.

Misura la chiusura

Le metriche servono a trovare lavoro residuo, non a celebrare il progetto.

Conta input arrivati al vecchio percorso dopo il cutoff, azioni esterne residue, item senza esito, dipendenze non migrate, accessi oltre la data prevista e richieste finite nel fallback. Il target viene dal piano. Per azioni che dovevano fermarsi, il numero accettabile è spesso zero.

Registra anche il tempo impiegato dal fallback e i casi respinti. Se il manuale non regge il volume reale, il bisogno non è stato chiuso. Hai solo spostato il collo di bottiglia.

Errori che lasciano il workflow mezzo vivo

• cancellare il progetto prima di avere l'inventario delle dipendenze,
• spegnere lo schedule ma lasciare webhook e retry,
• revocare un accesso prima di esportare le prove autorizzate,
• copiare segreti nel verbale di chiusura,
• lasciare item aperti senza owner ed esito,
• chiamare fallback una procedura mai provata,
• confondere dismissione del workflow con cancellazione automatica dei dati,
• non avvisare chi dipende dall'output.

L'ultimo input

Scegli il workflow che tutti chiamano ancora temporaneo. Trova l'ultimo input, l'ultima azione e la prima persona che si accorgerebbe dello spegnimento.

Tre righe. Da lì esce il piano vero.

Porta alla consulenza roadmap e governance AI di MAIKER HUB l'inventario e 1 workflow da chiudere. Nel percorso Think -> Build -> Enable costruiamo cutoff, fallback e prove senza lasciare in giro un sistema mezzo attivo.