Come creare una matrice di approvazione per workflow AI

Scenario fittizio. Alle 16:42 un workflow prepara 28 email. Le fonti sono corrette. In 1 email, però, la data proposta non è nel brief. Il team scrive serve review umana e passa il file a marketing.

Chi può approvarlo? Con quali prove? Entro quando? E cosa succede se marketing non risponde?

Una matrice di approvazione per workflow AI risponde prima che l'output esista. Collega ogni classe di output a conseguenza, reversibilità, prova minima, reviewer, scadenza e fallback. Se manca una riga, il workflow non esce.

Noi la chiamiamo matrice del diritto di far uscire. Il nome è scomodo apposta. Costringe a separare chi prepara da chi ha il diritto di trasformare una bozza in una decisione o in un'azione.

La review umana non basta

Controllo umano descrive una presenza. Non descrive un potere.

Una persona può leggere un output senza avere il contesto per valutarlo. Può conoscere il tema, ma non la policy. Oppure può sapere che la frase è sbagliata e non avere il diritto di bloccare l'invio.

Il NIST AI RMF tratta ruoli, responsabilità e linee di comunicazione come elementi da documentare. Distingue anche i ruoli nelle configurazioni umano-AI e chiede che la supervisione sia definita, valutata e documentata. Il framework non prescrive la matrice qui sotto. Offre il criterio: scrivere chi fa cosa e come l'output viene usato.

Se la tua procedura dice soltanto un umano approva, restano 5 buchi:

1. quale umano,
2. quale parte controlla,
3. quale prova deve vedere,
4. quanto può aspettare il workflow,
5. cosa accade quando l'approvazione manca.

Questi buchi non si chiudono con un altro prompt.

Disegna prima il confine di uscita

Parti dall'azione successiva, non dal testo generato.

Una bozza salvata in uno spazio di prova ha una conseguenza diversa da una mail inviata. Una riga suggerita in un CRM è diversa dalla stessa riga scritta nel CRM. Un riassunto interno può essere reversibile. Una conferma a un cliente può non esserlo.

Per ogni output completa questa frase:

Il workflow prepara [oggetto]. L'oggetto diventa [decisione o azione] quando [persona] verifica [prove]. Se la verifica manca, [fallback].

Esempio fittizio:

Il workflow prepara una bozza email. La bozza può essere inviata quando l'account owner verifica destinatario, data, claim e allegato contro il brief approvato. Se la verifica manca entro le 17:30, la bozza resta in coda.

La frase contiene già metà matrice. Ha oggetto, cambio di stato, reviewer, evidenza, tempo e stop.

La checklist per verificare un output AI aiuta a controllare il singolo risultato. La matrice decide chi applica quel controllo e quale esito serve per far uscire il risultato.

Classifica conseguenza e reversibilità

Non assegnare il reviewer in base al reparto che usa il workflow. Parti da 2 domande.

Prima: se l'output è sbagliato, chi o cosa subisce la conseguenza? Seconda: dopo l'errore, puoi tornare indietro senza creare un nuovo danno?

Puoi usare 4 classi iniziali. Sono una scelta di progetto, non uno standard NIST.

Classe	Stato dell'output	Esempio	Regola di uscita
A	prova isolata	sintesi su dati fittizi	resta nello spazio di prova
B	bozza interna reversibile	schema riunione non condiviso	reviewer operativo
C	comunicazione o record esterno	email, proposta, aggiornamento CRM	owner del processo e prove complete
D	azione difficile da annullare o ad alta conseguenza	pagamento, decisione su persone, modifica di permessi	bloccata o affidata a percorso competente separato

La classe non misura quanto è elegante il testo. Misura cosa può accadere dopo.

Un output di 4 parole può stare in D. Un report di 20 pagine può stare in B.

Scrivi le prove minime

Il reviewer non dovrebbe ricostruire il caso da zero. Riceve un pacchetto di evidenze proporzionato alla decisione.

Per una bozza fattuale possono servire fonte, data di verifica e passaggio del brief. Per un calcolo servono input, formula e unità. Per una classificazione servono criterio, casi limite e possibilità di contestare l'esito. Per una comunicazione servono destinatario, versione approvata degli allegati e claim ammessi.

Ogni riga della matrice ha quindi un evidence_contract:

output_class: C
object: email-proposta
must_show:
  - source_refs
  - recipient
  - approved_claim_ids
  - attachment_version
must_be_empty:
  - unsupported_claims
  - unresolved_conflicts

Qui tocca essere noiosi. Fonti controllate non è una prova. F03 e F07, consultate il 15/08/2026 lo è.

Il reviewer può approvare, respingere o chiedere una correzione. Non dovrebbe cambiare di nascosto il criterio dopo aver visto l'output. Se la prova minima non basta, si aggiorna la matrice per il giro successivo e si registra il motivo.

Assegna chi conosce la conseguenza

L'autore del prompt conosce il workflow. Non per forza conosce il rischio commerciale, legale, operativo o umano dell'uscita.

Assegna il reviewer più vicino alla conseguenza:

Conseguenza	Reviewer possibile	Cosa deve conoscere
dato fattuale sbagliato	owner della fonte	versione, data, campo autorevole
promessa esterna	account o owner commerciale	claim ammessi e impegno creato
cambio operativo	process owner	dipendenze, eccezioni e rollback
decisione su persone	funzione competente	regole, diritti, contestazione e limiti
accesso o permesso	owner tecnico autorizzato	scope, identità, durata e revoca

Una riga può richiedere 2 approvazioni. Succede quando esistono 2 conseguenze diverse. Evita però il tutti approvano tutto: diluisce il blocco e rende impossibile sapere chi ha deciso.

La consulenza roadmap e governance AI serve proprio quando prompt, processo e diritto di decisione non coincidono.

Aggiungi scadenza e fallback

Un'approvazione senza tempo massimo crea una coda invisibile. Il team, dopo 2 ore, inventa una scorciatoia.

La matrice deve dire quando scade la richiesta e cosa accade dopo. I fallback sicuri sono pochi: resta in coda, torna all'autore, passa a un sostituto già nominato oppure viene annullata.

Procedi se nessuno risponde non è un fallback. È un'approvazione automatica travestita.

Esempio:

Output	Reviewer	Tempo	Se manca risposta
bozza FAQ interna	knowledge owner	8 ore lavorative	torna in coda
email con data evento	event owner	2 ore lavorative	annullata
aggiornamento permesso	security owner	nessun timeout automatico	resta bloccato

Il tempo non va copiato da questa tabella. Dipende dal processo. Va deciso prima e provato durante l'onboarding AI in azienda, quando la persona può ancora sbagliare senza pressione reale.

Prova la matrice con casi contrari

Una matrice funziona quando regge l'eccezione, non quando descrive il caso felice.

Prendi 4 casi:

• output corretto e prove complete,
• output corretto con 1 prova mancante,
• output sbagliato ma scritto bene,
• reviewer assente oltre il tempo previsto.

Per ciascuno chiedi a una persona diversa di applicare la matrice. Non spiegare a voce. Osserva quale riga usa, quali prove cerca e dove si ferma.

Se 2 persone scelgono classi diverse, la definizione è ambigua. Se approvano perché sembra giusto, manca un evidence contract. Se nessuno sa cosa fare quando il reviewer è assente, manca il fallback.

Un buon test produce una decisione ripetibile. Non deve produrre sempre approvato.

Un esempio completo

Scenario fittizio: un chatbot interno prepara risposte su procedure di rimborso, usando soltanto una knowledge base approvata. I requisiti di un chatbot aziendale vengono prima della matrice. Definiscono fonti, confini e casi da fermare.

Output	Classe	Prova minima	Reviewer	Esito ammesso	Fallback
risposta su procedura presente	B	fact_id, data, passaggio citato	knowledge owner	approva o corregge	coda
risposta con 2 fonti discordanti	C	entrambe le fonti e conflitto	process owner	corregge o blocca	blocco
domanda su eccezione economica	D	nessuna risposta automatica	funzione competente	prende in carico	escalation
fonte scaduta	D	ID e data di scadenza	knowledge owner	blocca	blocco

La matrice non rende il chatbot autonomo. Rende visibile dove finisce la sua autonomia.

Misura il collo di bottiglia giusto

Conta ciò che aiuta a cambiare il processo: richieste per classe, tempo fino alla decisione, percentuale respinta, prove mancanti, fallback attivati e conflitti tra reviewer.

Non usare il numero di approvazioni come prova di qualità. Un team può approvare 100 output e controllarli male. Un altro può fermarne 8 perché la fonte è scaduta. Il secondo registro è più utile.

Se una classe riceve sempre lo stesso esito, indaga. Forse il controllo può essere semplificato. Oppure il reviewer approva per inerzia. Servono campioni e verifica, non una scorciatoia.

Gli errori che rompono la matrice

• assegnare manager senza nome di ruolo o sostituto,
• classificare in base alla lunghezza del testo,
• chiedere una review senza mostrare le fonti,
• lasciare che chi ha costruito il workflow approvi ogni uscita,
• usare il silenzio come consenso,
• cambiare soglia dopo aver visto il risultato,
• mettere email, CRM e pagamenti nella stessa classe,
• non registrare chi ha deciso e su quale versione.

La prima riga

Scegli l'output che oggi esce con un messaggio tipo me lo controlli al volo?. Scrivi oggetto, conseguenza, prova minima, reviewer, scadenza e fallback.

Una riga. Poi prova il caso in cui il reviewer non risponde.

Porta a MAIKER HUB il workflow e le 3 uscite che oggi non hanno un proprietario chiaro. Nel percorso Think -> Build -> Enable costruiamo la matrice, la proviamo su casi contrari e fermiamo ciò che non ha ancora il diritto di uscire.