Dal prompt al processo

In breve

È maturo per un processo un prompt che ha funzionato tre volte allo stesso modo, i cui input sono nominabili e i cui errori sarebbero riconoscibili.
Ne fanno parte quattro elementi: innesco, input, istruzione, destinazione dell'output, più una condizione di interruzione.
Una persona resta in esattamente due punti: nella valutazione e in tutto ciò che ha effetto verso l'esterno.
L'errore più frequente è il processo senza freno d'emergenza e senza registro: allora nessuno si accorge quando qualcosa si guasta.

Nella finestra di chat ogni errore è senza conseguenze: si legge la risposta e la si scarta. Un processo gira senza spettatori, ed è proprio questo a fare la differenza tra le due forme.

Quando un prompt è maturo per un processo

Tre condizioni, tutte insieme:

Ha funzionato tre volte allo stesso modo. Non in modo simile: uguale. Chi automatizza un prompt che ogni volta andava ritoccato automatizza via il ritocco, non il lavoro.
Gli input sono nominabili. Che cosa entra esattamente, e da dove viene? Se la risposta è «dipende», il processo non è ancora descrivibile.
Un errore sarebbe riconoscibile. Se un risultato sbagliato ha l'aspetto di uno giusto e nessuno guarda, manca il controllo, non l'automazione.

Attenzione «Lo faccio spesso» non è una condizione di maturità. La frequenza non dice nulla sull'uniformità. I compiti che si fanno spesso e ogni volta in modo diverso sono i candidati peggiori in assoluto, e sono quelli proposti più di frequente.

I quattro elementi

1. Innesco

Che cosa avvia il processo? Un momento («ogni lunedì alle 8»), un evento («nuova richiesta dal modulo») o un'azione («file depositato in una cartella»).

Errore frequente: un innesco che scatta troppo spesso. Ogni modifica di un record è di solito troppo; una volta al giorno basta.

2. Input

Quali dati entrano, da quale fonte, in che quantità? Qui ci vuole un limite di quantità, altrimenti prima o poi entra un elenco con 5.000 voci.

Errore frequente: nessun tetto massimo. Nelle prove non si nota, in esercizio subito.

3. Istruzione

Il prompt, ora fissato: situazione di partenza, compiti numerati, regole, forma dell'output. Con segnaposto per gli input.

Errore frequente: nessun divieto di invenzione. Nella chat un numero inventato si nota, nel processo no.

4. Destinazione dell'output

Dove va il risultato? Una bozza, una nota, un file, un messaggio a una persona. Possibilmente dove qualcuno guarda comunque.

Errore frequente: direttamente verso l'esterno. Invio, pubblicazione o modifica di un record senza passaggi intermedi.

Un processo nel dettaglio

Come esempio, l'analisi settimanale delle richieste ricevute: un processo che ha senso in quasi ogni azienda.

Elemento	Impostazione
Innesco	Lunedì, ore 7
Input	Richieste degli ultimi 7 giorni, al massimo 100, campi: data, fonte, esigenza, stato
Istruzione	Raggruppare per esigenza, nominare le tre più frequenti, scostamenti rispetto alla settimana precedente, non inventare numeri
Destinazione	E-mail alla direzione, al massimo 200 parole
Condizione di interruzione	Meno di 3 richieste: nessun invio
Registro	Momento, numero di input, esito o errore

Lo sapevi?

La condizione di interruzione è l'elemento che manca più spesso, e quello che evita più fastidi. Senza di essa il processo gira anche quando non c'è nulla, e produce un report sul nulla.

Il danno non è quel singolo report inutile. È che un report settimanale che spesso non contiene nulla, dopo due mesi non viene più letto, nemmeno quando una volta contiene qualcosa di importante. Un processo che segnala solo quando c'è qualcosa da segnalare resta utile per anni.

Dove resta la persona

Due punti, e non sono negoziabili:

Nella valutazione. Se un contatto sia interessato sul serio, se un testo colpisca il tono giusto, se uno scostamento sia un problema o un caso: giudizi del genere poggiano su contesti che nei dati non ci sono.

In tutto ciò che ha effetto verso l'esterno. Invio, pubblicazione, cancellazione, pagamento. Non perché un modello ne sia incapace, ma perché lì un errore non si può più recuperare.

Dalla pratica

Uno schema che si ripete: il processo gira bene tre mesi, poi cambia un dettaglio nella fonte dati — un campo si chiama in modo diverso, una vista è stata rifatta. Il processo continua a girare e produce risultati sbagliati che hanno l'aspetto di quelli giusti.

Contro questo aiuta una sola cosa: un controllo di plausibilità dentro il processo stesso. «Se meno di tre campi sono compilati, interrompi e segnala.» Cinque minuti in fase di costruzione, e la differenza tra un processo che si ferma davanti a un problema e uno che per mesi scrive report sbagliati.

Che cosa va storto

Nessun freno d'emergenza. Ogni processo ha bisogno di un punto in cui fermarlo subito, noto prima che serva.
Nessun registro. Senza annotazioni non si può ricostruire che cosa è successo, quando e con quali dati.
Nessun responsabile. I processi invecchiano in silenzio. Senza una revisione trimestrale, dopo un anno un processo fa più danno che utile.
Istruzioni infilate di nascosto. Se il processo legge testo da fonti esterne — e-mail, moduli, documenti — vi può stare una richiesta che sembra un incarico. Contro questo funziona soprattutto un permesso ristretto.

Prompt

Vorrei trasformare un prompt ricorrente in un processo fisso.
Esamina il piano e scrivi il processo.

Il prompt che oggi uso a mano:
[inserire prompt]

Situazione di partenza:
- Con che frequenza lo faccio: [frequenza]
- Da dove arrivano gli input: [fonte]
- Che cosa succede al risultato: [descrizione]
- Finora dovevo adattare il prompt ogni volta? [sì / no]
- Entrano dati da fonti esterne (e-mail, moduli)? [sì / no]

Compiti:
1. Verifica le tre condizioni di maturità: ha funzionato tre
   volte allo stesso modo, input nominabili, errore
   riconoscibile. Dillo con chiarezza se una non è soddisfatta:
   allora il processo non è ancora il momento.
2. Scrivi i quattro elementi: innesco, input (con limite di
   quantità), istruzione con segnaposto, destinazione
   dell'output.
3. Formula una condizione di interruzione e un controllo di
   plausibilità che impedisca ai risultati sbagliati di sembrare
   giusti.
4. Indica i punti in cui deve decidere una persona.
5. Indica che cosa va registrato e come si ferma il processo.

Se il piano in questa forma non regge, dillo con chiarezza e
indica la versione ridotta.

Conclusione

Il passo dal prompt al processo non è un ostacolo tecnico ma una questione di descrivibilità. Chi sa scrivere innesco, input, istruzione e destinazione ha superato la parte difficile.

Ciò che poi fa la differenza sono le parti poco spettacolari: condizione di interruzione, controllo di plausibilità, registro, freno d'emergenza. Insieme costano venti minuti e decidono se dopo un anno un processo sarà ancora utile o farà danno in silenzio.

Domande frequenti

Come si automatizzano i processi di lavoro con l'IA?

Trasformando un prompt collaudato in quattro elementi: innesco (momento o evento), input (con fonte e limite di quantità), l'istruzione con segnaposto, e una destinazione per l'output, possibilmente dove qualcuno guarda comunque. Ne fanno parte una condizione di interruzione, un controllo di plausibilità e un registro.

Quando un prompt è maturo per un processo?

Quando tre condizioni sono soddisfatte insieme: ha funzionato almeno tre volte esattamente allo stesso modo, i suoi input si possono nominare, e un risultato sbagliato sarebbe riconoscibile. Che un compito si faccia spesso non basta: i compiti frequenti che ogni volta si svolgono in modo diverso sono i candidati peggiori.

Che cosa deve esserci per forza in ogni processo?

Una condizione di interruzione, perché il processo non giri quando non c'è nulla; un controllo di plausibilità che si fermi se gli input hanno un aspetto inatteso; un registro con momento, quantità ed esito; e una possibilità nota di fermarlo subito.

In quali punti deve restare una persona?

In due: nelle valutazioni che poggiano su contesti assenti dai dati — per esempio se un contatto sia interessato sul serio — e in tutto ciò che ha effetto verso l'esterno: invio, pubblicazione, cancellazione, pagamento. Lì un errore non è recuperabile.

Perché dopo mesi un processo fornisce risultati sbagliati?

Di solito perché la fonte dati è cambiata senza che si notasse: un campo si chiama in modo diverso, una vista è stata rifatta. Il processo continua a girare e produce risultati sbagliati che sembrano giusti. Contro questo aiutano un controllo di plausibilità nel processo stesso e una revisione trimestrale fissa.