Quando una persona dovrebbe approvare un’azione dell’IA?

Date un nome alla decisione che la persona sta prendendo.

Un pulsante «Approva» non dice a chi revisiona che cosa sta autorizzando. Sta accettando una bozza, confermando una classificazione, consentendo un messaggio esterno o approvando la modifica di un record aziendale? Queste decisioni hanno conseguenze diverse e possono spettare a persone diverse.

Iniziate separando la preparazione dall’esecuzione. Un workflow può raccogliere documenti, controllare i campi obbligatori e abbozzare una raccomandazione prima che qualcuno approvi un’azione con conseguenze. L’approvazione deve collocarsi immediatamente prima dell’azione che controlla, con gli ulteriori controlli richiesti dal sistema ricevente ancora in vigore.

Per un’offerta la decisione potrebbe essere: approvare questa versione per l’invio a questo destinatario a queste condizioni. Per la document intelligence potrebbe essere: accettare questo pacchetto di confronto come pronto per la revisione legale. Accettare un pacchetto non deve diventare tacitamente la firma di un contratto. Per la process intelligence, approvare una guida conferma il suo contenuto revisionato; non dà a chi legge un’autorità di spesa né l’accesso a un sistema ERP.

Date a chi revisiona un pacchetto di evidenze.

Una schermata di revisione utile riduce lo sforzo di controllo del risultato senza nascondere l’incertezza. Mettete l’azione proposta accanto alle evidenze che la sostengono. Mostrate l’input originale, i riferimenti alle fonti pertinenti, le modifiche rispetto alla versione precedente e gli eventuali controlli falliti.

Il pacchetto dovrebbe rispondere a queste domande:

• Che cosa succederà esattamente se approvo?
• Quale record, documento, destinatario o periodo di reporting viene toccato?
• Quali versioni delle fonti sono state usate, e sono abbastanza aggiornate per questa decisione?
• Che cosa ha calcolato il workflow, e che cosa ha dedotto o abbozzato l’IA?
• Quali limiti, eccezioni o conflitti irrisolti restano?
• Che cosa succede se rifiuto o chiedo modifiche?

Non fate del punteggio di confidenza di un modello l’unica evidenza. Una risposta sicura può comunque usare la fonte sbagliata o fraintendere l’azione prevista. Se chi revisiona deve cercare in più sistemi per ricostruire la base di ogni suggerimento, l’interfaccia di approvazione ha spostato il lavoro invece di renderlo più semplice.

Nella demo Document Intelligence, il confronto identifica le clausole di origine e i controlli sulle regole prima della revisione. È un esempio sintetico di pacchetto, non una consulenza legale né l’affermazione che un contratto reale sia stato verificato.

Vincolate l’approvazione alla persona, alla versione e all’azione.

Un record di approvazione ha bisogno di contesto sufficiente per non essere applicato in seguito a un’azione diversa. In un’implementazione reale, definite il ruolo autorizzato, l’azione proposta esatta, la versione di input o output ed eventuali scadenze. Usate la gestione di identità e accessi del cliente per stabilire chi può approvare; il solo possesso di un link non deve implicare il diritto di approvare.

Se l’offerta cambia dopo l’approvazione, la vecchia decisione non copre più l’offerta modificata. Se cambia un destinatario, verificate di nuovo. Se i dati di origine vengono aggiornati, decidete se quel cambiamento invalida la revisione precedente. Queste regole devono essere esplicite, non dedotte da un passaggio di IA.

Anche l’esecuzione ha bisogno di un proprio controllo. Un evento di approvazione e un’azione riuscita sono record diversi. Un timeout di rete dopo l’invio di un messaggio non dimostra che il messaggio non sia partito. Usate un identificativo di operazione e il meccanismo di riconciliazione o idempotenza supportato dal sistema ricevente per evitare di ripetere alla cieca un’azione con conseguenze.

Decidete che cosa succede quando nessuno approva.

Una richiesta senza risposta deve restare in sospeso o scadere secondo la regola concordata. Non deve trasformarsi in approvazione allo scadere di un timer. Un’azione rifiutata deve avere un motivo e un passo successivo chiaro: rivedere, inoltrare a un altro ruolo responsabile o fermarsi.

L’escalation richiede la stessa cura. Inviare un promemoria è diverso dal cedere il diritto di approvare. Se è ammesso un sostituto, definite quel ruolo in anticipo. Conservate il contesto originale quando un caso passa da una persona all’altra, così che chi subentra veda gli stessi punti irrisolti.

Se il servizio di approvazione non è disponibile o la risposta non è valida, fermate l’azione controllata e conservate stato sufficiente per riprendere. Evitate di chiedere a qualcuno di approvare un pacchetto vecchio quando sono già arrivati input più recenti. Tenete ben distinti l’attesa di una persona, il nuovo tentativo di un passaggio tecnico e l’indagine su un risultato di esecuzione incerto.

Testate i tentativi di aggirare l’approvazione.

Il percorso ideale è solo un caso. I test di accettazione devono coprire le situazioni in cui il workflow deve rifiutarsi di proseguire:

1. Chi revisiona rifiuta l’azione; l’esecuzione resta bloccata.
2. L’approvazione scade prima dell’esecuzione; serve una nuova decisione.
3. L’input cambia dopo la revisione; l’approvazione precedente non può essere riutilizzata.
4. Lo stesso messaggio di approvazione arriva due volte; l’azione non viene duplicata.
5. Qualcuno senza il ruolo appropriato prova ad approvare; il tentativo viene rifiutato.
6. Un sistema va in timeout dopo un tentativo di azione; il ripristino verifica l’esito prima di riprovare.
7. Il workflow viene rieseguito; il vecchio stato di approvazione non passa nella nuova esecuzione.

Le demo locali testano il comportamento di pausa, approvazione e reset. Non autenticano approvatori reali né esercitano il modello di autorizzazioni di un cliente. Per questo servono test di integrazione con i sistemi scelti e il fornitore di identità. Mantenete questa distinzione nelle evidenze che usate per decidere se avviare.

Rendete la revisione proporzionata e degna dell’attenzione della persona.

Richiedere l’approvazione per ogni innocuo passaggio di formattazione crea una coda di clic. Non richiederne alcuna per le azioni visibili all’esterno crea un problema diverso. Raggruppate il lavoro di preparazione a bassa conseguenza, poi ponete un passaggio di approvazione chiaro prima della decisione che conta.

Misurate quanto dura la revisione, quanto spesso chi revisiona modifica la bozza e quanti casi richiedono escalation. Tassi di approvazione elevati da soli non dimostrano che il processo funzioni: le persone potrebbero approvare senza evidenze sufficienti. Campionate la qualità delle decisioni oltre al volume.

Nelle aziende più grandi possono essere appropriate responsabilità di revisione separate. Un esperto della materia può confermare la correttezza mentre un responsabile aziendale autorizzato consente il rilascio. Nei team più piccoli la stessa persona può ricoprire entrambi i ruoli, ma le due decisioni devono restare comprensibili.

L’obiettivo è un’interfaccia che mostri chiaramente chi può approvare cosa. Consultate i principi di ingegneria, l’ esempio Process Intelligence oppure usate il Workflow Fit Checker per individuare dove il vostro passaggio di approvazione è ancora poco chiaro.