Come scrivere una SOP per un workflow AI aziendale

La persona che ha costruito il workflow è in ferie. Arriva un input incompleto. Il collega apre il documento e trova 3 pagine sul prompt, ma nessuna riga su chi deve decidere.

Quella non è una SOP. È la memoria del progettista messa in bella copia.

Una SOP per un workflow AI spiega come eseguire un compito, come controllarlo e come fermarlo. Deve funzionare anche quando manca la persona che conosce tutti i retroscena. Se documenta soltanto il percorso felice, lascia il team solo proprio nel punto in cui serve una regola.

Il formato che usiamo si chiama SOP a 2 corsie: una corsia porta dall'input all'output. L'altra porta dal problema all'escalation, senza chiedere al modello di riempire il vuoto.

Fai il test della sostituzione

Prendi una persona che conosce il processo ma non ha scritto il workflow. Consegnale procedura, accessi di prova e un caso ripulito. Non darle una spiegazione a voce.

Osserva 4 cose:

Domanda	Cosa rivela
Sa scegliere l'input giusto?	confine operativo
Sa avviare il workflow senza inventare passaggi?	chiarezza della procedura
Sa controllare il risultato?	qualità del gate
Sa fermarsi nel caso sbagliato?	maturità dello stop path

Se deve scrivere all'autore per capire ogni eccezione, la SOP non è autonoma. Se prosegue anche quando manca una fonte, è peggio: sembra autonoma, ma non è controllata.

La mappa delle competenze AI aiuta a capire chi può eseguire e chi deve guidare. La SOP non sostituisce quella decisione. La rende visibile nel lavoro.

Separa policy, prompt e SOP

I 3 oggetti rispondono a domande diverse.

Oggetto	Domanda	Esempio
policy	cosa è ammesso e chi risponde	dati che non possono entrare nel tool
SOP	come si esegue e dove si ferma	sequenza, controlli, escalation
prompt	cosa chiedi al modello in un passaggio	formato della bozza e fonti da usare

Mettere la policy dentro il prompt la nasconde a chi deve approvarla. Mettere tutta la SOP dentro il prompt crea un blocco difficile da verificare. Lascia il prompt nella versione controllata del workflow e richiamalo dalla procedura con un ID.

Una scelta netta: la SOP deve spiegare il processo anche a tool spento. Se senza ChatGPT, Claude o Gemini non sai descrivere cosa entra, cosa esce e chi approva, il processo non è ancora definito.

NIST AI RMF Map 2.1 indica di definire compiti e metodi supportati dal sistema AI. Map 2.2 aggiunge limiti, uso degli output e supervisione umana. Non impone questo layout. Conferma però il punto operativo: un workflow non è soltanto una chiamata al modello.

Apri con un frontespizio di 9 campi

Il frontespizio serve a decidere se la procedura è quella giusta prima di iniziare.

SOP ID:
Titolo:
Owner del processo:
Esecutore ammesso:
Scopo:
Trigger di avvio:
Output ammesso:
Versione:
Data di revisione:

Scopo: usare l'AI per i report è troppo largo. Scrivi preparare la prima bozza della sezione decisioni da 4 fonti approvate. Il campo output deve dire anche cosa non è: bozza interna, non invio e non approvazione finale.

Versione e data di revisione non sono decorazioni. Un cambio di modello o di fonte può rendere vecchia una procedura rimasta identica nel titolo.

Corsia 1: dal trigger all'output controllato

La corsia normale non racconta ogni clic. Descrive i passaggi che cambiano lo stato del lavoro.

Usa questa forma:

azione -> evidenza -> gate

Esempio fittizio per una scheda decisione:

Passo	Azione	Evidenza	Gate
1	raccogli F01-F04 dalla cartella approvata	elenco ID e hash	4 fonti presenti
2	rimuovi campi non ammessi	log di pulizia	nessuna PII
3	esegui prompt P-07 v3	output grezzo	run ID salvato
4	confronta ogni decisione con le fonti	matrice claim-fonte	100% dei fatti collegati
5	assegna esito passa, correggi, chiedi o ferma	checklist firmata	nessun errore critico
6	consegna la bozza al reviewer	link al pacchetto	reviewer identificato

I numeri descrivono l'esempio. Non sono una soglia per ogni azienda.

Ogni passaggio deve avere un verbo eseguibile. Verificare la qualità è un titolo. Confronta date, importi e owner con F01-F04 è un'azione.

Corsia 2: lo stop path

La maggior parte delle procedure diventa vaga qui. Scrive in caso di dubbio contattare il responsabile. Quale dubbio? Quale responsabile? Entro quando? Nel frattempo l'output resta fermo o prosegue?

Costruisci una tabella dei trigger.

Trigger	Azione immediata	Destinatario	Evidenza	Ripresa
fonte mancante	non generare il claim	source owner	ID fonte assente	dopo caricamento approvato
2 date in conflitto	conserva entrambe	process owner	estratti F02 e F04	dopo decisione registrata
PII nell'input	interrompi e non copiare	privacy owner definito internamente	solo codice evento, non il dato	dopo input ripulito
output oltre il perimetro	scarta la parte	reviewer	sezione e motivo	nuova esecuzione limitata
tool non disponibile	usa percorso manuale approvato	operations	timestamp e stato	nessun retry cieco

La SOP non deve inventare il privacy owner. Deve riportare quello deciso dall'organizzazione. Se manca, il trigger resta bloccato prima dell'uso.

Mo' arriva la parte che tutti vorrebbero saltare: provare lo stop davvero. Inserisci un conflitto noto e guarda se la persona si ferma. Leggere la tabella non dimostra che la userà.

Scrivi chi può decidere cosa

Un reviewer generico non basta. Separa 4 responsabilità, anche quando 2 ricadono sulla stessa persona.

Ruolo	Decisione
process owner	definisce risultato e soglie
tool owner	mantiene accesso e configurazione approvata
esecutore	applica la SOP e registra i controlli
reviewer	approva, corregge o ferma l'output

Per i team piccoli puoi scrivere process owner e reviewer: stessa persona. La sovrapposizione dichiarata è controllabile. Quella implicita no.

La consulenza su roadmap e governance AI lavora su questo strato: responsabilità, dati, priorità e gate. La SOP porta quelle decisioni sul tavolo operativo.

Conserva l'evidenza minima

Non serve archiviare ogni conversazione per sempre. Serve lasciare ciò che permette di ricostruire una decisione, nel rispetto delle regole interne.

Per ogni esecuzione valuta questi campi:

run_id: WD-2026-0814-017
sop_version: 1.3
prompt_version: P-07-v3
input_refs: [F01, F02, F03, F04]
output_ref: O-017
checks: [fonti, date, owner, perimetro]
exceptions: [date-conflict-D02]
decision: chiedi
reviewer: role-process-owner
decided_at: null

L'esempio non contiene nomi reali. Nel sistema aziendale l'identità e i tempi di conservazione vanno gestiti secondo policy. Non copiare PII nel log per dimostrare che hai trovato PII.

Una SOP completa in 1 pagina operativa

Ecco un esempio ridotto. I riferimenti sono fittizi.

SOP WD-03 v1.3
Scopo: preparare una bozza di scheda decisione da F01-F04.
Output: bozza interna. Nessun invio automatico.

AVVIO
1. Verifica che F01-F04 siano presenti e approvate.
2. Se trovi PII, ferma e richiedi input ripulito.
3. Esegui P-07-v3 e salva il run ID.

CONTROLLO
4. Collega ogni fatto a una fonte.
5. Confronta date, owner e stato.
6. Marca passa, correggi, chiedi o ferma.

STOP
- Fonte mancante: nessun claim.
- Date discordanti: mostra entrambe, non scegliere.
- Owner assente: escalation al process owner.
- Output fuori scopo: scarta e rilancia con perimetro corretto.

CHIUSURA
7. Salva output, correzioni e decisione.
8. Il reviewer firma prima dell'uso.

La pagina operativa può linkare allegati più lunghi, come policy dati, rubriche e prompt. Non deve duplicarli. Duplichi una regola, crei 2 versioni della verità.

Prova 3 guasti, non soltanto il percorso felice

Prima del rilascio locale della SOP esegui una prova da tavolo:

1. input completo,
2. fonte mancante,
3. conflitto tra 2 fonti.

Chiedi a una persona diversa dall'autore di seguire il documento. Registra dove ha dovuto interpretare. Ogni interpretazione necessaria diventa una correzione candidata.

Non correggere a voce durante la prova. Se la persona sbaglia perché la frase è ambigua, il difetto appartiene alla SOP.

Le office hours AI in azienda possono raccogliere eccezioni ricorrenti dopo l'avvio. Non devono diventare il posto dove ogni settimana si rispiega una procedura mai aggiornata.

Cambia una cosa, cambia la versione

Non tutti i cambi meritano lo stesso numero.

Cambio	Esempio	Versione candidata
correzione editoriale	refuso senza effetto operativo	patch
passaggio o controllo	nuovo gate sulle date	minor
scopo, owner o output	invio esterno prima vietato	major e nuova approvazione

Il criterio è l'effetto sul lavoro, non la quantità di righe. Aggiungere una sola azione automatica può cambiare più di 2 pagine di spiegazione.

NIST AI RMF include il monitoraggio del comportamento mentre il sistema è in uso. Per una SOP significa avere un canale che riporta errori reali alla procedura. Un documento approvato e mai rivisto non monitora nulla.

Segnali che la SOP non regge

• dipende da una spiegazione a voce,
• contiene usa il buon senso senza criterio,
• mostra il prompt ma non il risultato atteso,
• descrive il percorso normale e nasconde gli stop,
• assegna tutto a un responsabile non nominato per ruolo,
• non distingue bozza, approvazione e azione,
• salva dati non necessari come prova,
• non ha versione o data di revisione,
• cambia dopo un incidente senza aggiungere il caso di prova.

La roadmap per integrare l'AI in azienda evita di moltiplicare SOP su casi non prioritari. Prima scegli il processo. Poi documenti quello che deve girare davvero.

La prima SOP da mettere alla prova

Scegli il workflow che oggi dipende di più da una persona. Scrivi trigger, output e 3 condizioni di stop. Consegnalo a un collega con un caso ripulito.

Se chiude senza chiamarti, hai una procedura. Se si ferma nel punto giusto, hai una procedura controllata.

Porta a MAIKER HUB il processo, il passaggio che si rompe e l'owner che deve decidere. Nel percorso Think -> Build -> Enable costruiamo la SOP a 2 corsie e la proviamo prima di affidarle lavoro reale.