AI ADOPT™ — Livello 3

Modulo 1
Mappa il tuo processo

Inserisci la password ricevuta via email per accedere al corso.

Password di accesso

Per assistenza: info@ai-adopt.it

AI ADOPT™ | L3 — Modulo 1: Mappa il tuo processo
← Tutti i moduli
Lezione 1/3
A — Assess · Modulo 1

Mappa il tuo processo

Automatizzare il processo sbagliato è peggio che non automatizzare nulla. Prima di toccare qualsiasi strumento, devi capire quale processo vale la pena affidare a un agente, come funziona esattamente e dove si nascondono i rischi. Questo modulo ti dà il metodo per farlo in modo sistematico.

Fase A — Assess
Lezioni 3
Durata stimata 55 minuti
Attività Simulazione decisionale, Completamento scheda, Analisi di caso
Sezione 1 di 4

Non tutti i processi sono candidati

Uno degli errori più comuni nell'adozione degli agenti AI è scegliere il processo da automatizzare in base all'entusiasmo o alla visibilità, non alla struttura. Un processo complesso, ricco di eccezioni e con output difficile da valutare non diventa più semplice se ci metti un agente sopra: diventa più opaco e più costoso quando qualcosa va storto.

Il punto di partenza è sempre la domanda: questo processo ha le caratteristiche giuste per essere gestito da un agente AI no-code? Quattro criteri ti aiutano a rispondere con precisione.

Criterio Cosa significa Segnale positivo Segnale di attenzione
Volume Quante volte si ripete il processo in un dato periodo Almeno 5-10 volte a settimana, con picchi prevedibili Occasionale o stagionale senza schema fisso
Ripetitività Quanto è costante la struttura del processo da un'esecuzione all'altra Lo stesso schema si ripete con variazioni minori e prevedibili Ogni esecuzione richiede giudizio situazionale diverso
Input/Output Quanto sono definiti i dati in ingresso e il risultato atteso Input chiari e strutturati, output verificabile oggettivamente Input ambigui, output soggettivo o dipendente dal contesto
Costo errore Quali conseguenze ha un errore dell'agente su questo processo Errore visibile e correggibile prima che raggiunga il cliente o produca danni Errore invisibile o con conseguenze legali, finanziarie o reputazionali dirette
Regola pratica

Un processo che supera tutti e quattro i criteri è un candidato forte. Tre criteri su quattro è ancora un buon punto di partenza. Meno di tre significa che l'agente probabilmente genererà più problemi di quanti ne risolva — almeno nella versione iniziale.


Sezione 2 di 4

La matrice impatto-fattibilità

Quando hai più processi candidati — situazione comune nelle PMI che iniziano a esplorare l'automazione — hai bisogno di un modo per confrontarli e decidere da dove iniziare. La matrice impatto-fattibilità è lo strumento più diretto: due assi, quattro quadranti, una priorità chiara.

Impatto misura quanto tempo, denaro o errori si risparmia automatizzando il processo. Fattibilità misura quanto è semplice costruire l'agente con strumenti no-code, tenendo conto della struttura del processo, della qualità dei dati disponibili e della complessità tecnica delle integrazioni necessarie.

Fattibilità bassa
Fattibilità media
Fattibilità alta
Impatto alto
Sfida strategica — investi tempo prima di automatizzare
Priorità alta — pianifica e costruisci con cura
Inizia subito — massimo ritorno con minimo sforzo
Impatto medio
Valuta se vale la pena
Seconda ondata — dopo aver consolidato i primi agenti
Buona scelta di apprendimento — basso rischio
Impatto basso
Evita — complessità non giustificata
Evita per ora
Esercizio utile — ma non come primo agente

Il quadrante ideale per il primo agente è quello in alto a destra: alta fattibilità, alto impatto. Se non hai processi in quel quadrante, il secondo migliore è alto impatto e media fattibilità — ma in quel caso dedica più tempo alla fase di progettazione prima di costruire.


Sezione 3 di 4

Cinque processi di uno studio commercialista: un esercizio

Per rendere concreto il metodo, prendiamo uno studio di consulenza fiscale con cinque processi ricorrenti. Ognuno viene valutato rispetto ai quattro criteri e posizionato nella matrice. L'obiettivo non è la risposta giusta in assoluto — dipende dal contesto specifico — ma capire come ragionare sulla selezione.

Processo 1
Raccolta documenti per dichiarazione dei redditi

Volume alto (stagionale ma concentrato), struttura costante, input definibili (lista documenti per tipo di contribuente), output verificabile (cartella completa o incompleta). Fattibilità alta, impatto alto.

Processo 2
Risposta a quesiti fiscali dei clienti

Volume medio, ma ogni quesito richiede ragionamento giuridico situazionale. Output difficile da verificare oggettivamente. Costo dell'errore potenzialmente alto. Fattibilità bassa — non adatto a un agente autonomo.

Processo 3
Notifica scadenze fiscali ai clienti

Volume alto, struttura fissa (calendario scadenze + anagrafica clienti + template email), output verificabile (email inviata o non inviata). Fattibilità molto alta, impatto medio-alto. Ottimo primo agente.

Processo 4
Predisposizione prima nota contabile

Volume alto, struttura relativamente costante per i clienti standard, ma richiede accesso ai sistemi gestionali e verifica umana obbligatoria per ogni registrazione. Fattibilità media, impatto alto — adatto come chain con supervisione.

Processo 5
Onboarding nuovi clienti

Volume basso ma con schema fisso (raccolta dati, verifica antiriciclaggio, apertura fascicolo, configurazione nel gestionale, invio lettera incarico). Fattibilità media-alta come chain a più nodi. Impatto medio — buona scelta per la seconda ondata di automazione.


Sezione 4 di 4

Come scegliere il tuo processo candidato

Ora che hai il metodo, applicalo al tuo contesto. Il modo più efficace è fare una lista di tutti i processi ripetitivi che svolgi o che il tuo team svolge — anche quelli che sembrano troppo semplici per meritare attenzione. Spesso sono proprio quelli che producono il maggior ritorno quando automatizzati, perché il loro volume cumulativo è enorme.

Nella lista, assegna a ciascun processo un punteggio approssimativo su impatto e fattibilità (alto / medio / basso). Non serve precisione: l'obiettivo è distinguere i candidati forti da quelli deboli, non costruire un modello quantitativo perfetto.

Il processo che emerge come prioritario diventerà il filo conduttore del corso: lo userai come caso reale nel Modulo 2 per scrivere le istruzioni, nel Modulo 3 per costruire il workflow, nel Modulo 4 per testarlo e nel Modulo 6 per il pilot.

Prompt pronto all'uso
Valutazione di una lista di processi candidati
Lavoro come [ruolo] in uno [tipo di studio/azienda]. Ecco una lista di processi ripetitivi che svolgo regolarmente:

1. [processo] — frequenza: [x volte a settimana/mese]
2. [processo] — frequenza: [x volte a settimana/mese]
3. [processo] — frequenza: [x volte a settimana/mese]

Per ciascuno, valuta: volume, ripetitività, chiarezza di input e output, costo potenziale dell'errore. Poi posizionali in una matrice impatto-fattibilità e dimmi quale affrontare per primo con un agente AI no-code e perché.
DigComp 2.2 — Area 5.1 AI Act — Art. 9

Identificare i bisogni e rispondere con soluzioni digitali appropriate: la selezione del processo da automatizzare è una decisione strategica che richiede valutazione critica, non solo entusiasmo per la tecnologia.

Attività — Simulazione decisionale Scegli il processo giusto per la prima automazione
Sei il responsabile operativo di un'agenzia di comunicazione con 8 persone. Ogni mese gestisci questi processi ricorrenti:

A. Raccolta e archiviazione dei report mensili di performance inviati dai clienti via email (circa 15 clienti, schema fisso, stessa struttura ogni mese)
B. Risposta alle richieste di nuovi brief creativi (ogni brief è unico, richiede valutazione del concept e del budget)
C. Invio promemoria agli art director per le scadenze di consegna degli asset (ogni progetto ha scadenze diverse, ma il processo di notifica è sempre lo stesso)
D. Elaborazione delle fatture mensili per i clienti ricorrenti (importi fissi, stessa struttura, collegato al gestionale)

Qual è il processo migliore su cui costruire il primo agente AI no-code?
A — Raccolta e archiviazione dei report mensili
B — Risposta alle richieste di nuovi brief creativi
C — Invio promemoria scadenze agli art director
D — Elaborazione fatture mensili clienti ricorrenti
← Modulo 0 Lezione 1 di 3
Sezione 1 di 4

Tre livelli per descrivere un processo

Una volta scelto il processo candidato, il passo successivo è descriverlo con la precisione necessaria per istruire un agente. Non basta sapere "cosa si fa": serve capire cosa scatena il processo, cosa entra nel sistema, e cosa deve uscire — e in che forma, per chi, entro quando.

Questa descrizione a tre livelli è la base di tutto quello che costruirai nei moduli successivi. Se è imprecisa, le istruzioni dell'agente saranno imprecise. Se è completa, la costruzione del workflow sarà molto più rapida e meno soggetta a correzioni.

Livello 1
Trigger
Cosa avvia il processo? Un evento esterno (email ricevuta, form compilato, data calendario), un'azione umana (click, approvazione), o un dato che cambia stato (ordine confermato, documento caricato)?
Livello 2
Input
Cosa entra nel processo? Dati strutturati (form, tabella, API) o non strutturati (email, PDF, messaggio)? Da dove arrivano? Chi li produce? Quanto sono variabili?
Livello 3
Output
Cosa deve produrre il processo? Documento, notifica, aggiornamento database, email, report? In quale formato? Per chi? Con quale livello di completezza prima della consegna?
Risultato
Scheda di mappatura
Un documento di una pagina che descrive il processo con sufficiente precisione da permettere la configurazione dell'agente senza ambiguità.

Sezione 2 di 4

Trigger umano vs. trigger automatico: una distinzione critica

Non tutti i trigger sono uguali, e la differenza ha implicazioni dirette sulla configurazione del tuo agente. Un trigger umano richiede che qualcuno compia un'azione deliberata per avviare il processo. Un trigger automatico si attiva da solo, senza intervento di nessuno.

La maggior parte degli agenti no-code per PMI si basa su trigger automatici — ed è proprio lì che risiede il valore: il processo parte senza che nessuno debba ricordarsi di avviarlo. Ma questo significa anche che l'agente deve gestire correttamente tutti i casi che arrivano, compresi quelli anomali, perché nessuno sta guardando in tempo reale.

Tipo di trigger Esempi Implicazione per l'agente
Automatico — evento Email ricevuta, form compilato, documento caricato su Drive, ordine confermato L'agente deve gestire tutti i casi possibili; serve un guardrail per gli input anomali
Automatico — tempo Ogni lunedì alle 8:00, il primo giorno del mese, 3 giorni prima della scadenza Semplice da configurare, ma l'agente non sa se le condizioni sono cambiate dall'ultima esecuzione
Umano — esplicito Click su un bottone, invio di un comando, approvazione di un record Più controllato, ma richiede che qualcuno sia presente e ricordi di agire
Umano — implicito Cambio di stato di un record che dipende da un'azione umana (es. stato ordine → "confermato") Ibrido: automatico nella catena, ma dipende da un'azione umana a monte

Sezione 3 di 4

La scheda di mappatura: struttura e campi

La scheda di mappatura è il documento che userai come riferimento per costruire l'agente. Non è un documento tecnico — è una descrizione strutturata del processo in linguaggio naturale, organizzata nei campi che un agente AI ha bisogno di conoscere per funzionare correttamente.

Compilarla richiede tra i 20 e i 40 minuti per un processo di media complessità. Il tempo è ben speso: ogni campo che lasci vuoto o ambiguo si tradurrà in almeno un ciclo aggiuntivo di test e correzione durante la costruzione.

Nome del processo
Un nome preciso e riconoscibile, non generico.
Es: "Notifica scadenze mensili ai clienti"
Trigger
Cosa avvia il processo, di che tipo è (automatico/umano), con quale frequenza o condizione.
Es: "Automatico — ogni 1° del mese alle 9:00"
Input
Tutti i dati necessari al processo: fonte, formato, variabilità.
Es: "Lista clienti su Airtable + calendario scadenze su Google Sheet"
Output atteso
Il risultato concreto: tipo di documento/azione, formato, destinatario.
Es: "Email personalizzata per ogni cliente con le scadenze del mese"
Chi riceve l'output
Cliente finale, collega, sistema esterno, log interno.
Es: "Cliente (email diretta) + copia al responsabile account"
Eccezioni note
Casi che si discostano dal percorso standard e richiedono gestione diversa.
Es: "Clienti in moratoria non ricevono notifica — flag su Airtable"
Punto di supervisione umana
Dove l'output deve essere verificato prima di procedere, e da chi.
Es: "Nessuno — ma log giornaliero inviato al responsabile"
Strumenti coinvolti
Tutti i sistemi da cui l'agente deve leggere o su cui deve scrivere.
Es: "Airtable (clienti), Google Sheets (scadenze), Gmail (invio)"

Sezione 4 di 4

Due esempi di mappatura completa

Vedere la scheda compilata su casi reali è il modo più rapido per capire il livello di dettaglio richiesto. Il primo esempio è semplice — un agente singolo con trigger automatico. Il secondo è più articolato, con un trigger ibrido e un punto di controllo esplicito.

Esempio 1 — Agenzia viaggi: pre-qualifica richieste online

Trigger: automatico — ricezione email dal form del sito con oggetto standardizzato. Input: testo email con destinazione, date, numero persone, budget indicativo. Output: scheda cliente pre-compilata su Notion + classificazione (richiesta standard / richiesta complessa / fuori target budget). Chi riceve: consulente assegnato via notifica Slack. Eccezioni: email senza date o budget → classificazione automatica come "incompleta" + risposta al cliente con richiesta di integrazione. Supervisione: nessuna sull'invio della notifica; il consulente decide l'azione successiva.

Esempio 2 — Studio legale: apertura fascicolo nuovo mandato

Trigger: umano esplicito — avvocato segna il cliente come "accettato" nel CRM. Input: dati anagrafici cliente, tipo di mandato, avvocato referente, data di accettazione. Output: fascicolo su Notion con template standard + bozza lettera di incarico in Google Docs + reminder calendario per primo appuntamento. Chi riceve: avvocato referente (email con link ai documenti) + segreteria (notifica). Eccezioni: mandati con più parti → creazione fascicoli multipli collegati. Supervisione: l'avvocato referente deve approvare la lettera di incarico prima dell'invio al cliente.

Prompt pronto all'uso
Compilazione guidata della scheda di mappatura
Aiutami a compilare la scheda di mappatura per questo processo: [descrizione libera del processo]

Fai le domande necessarie per identificare con precisione: trigger (tipo e condizione), input (fonte, formato, variabilità), output atteso (tipo, formato, destinatario), eccezioni note, punto di supervisione umana, strumenti già in uso coinvolti nel processo.

Fai una domanda alla volta. Quando hai tutte le informazioni, genera la scheda compilata in formato strutturato.
DigComp 2.2 — Area 2.1 AI Act — Art. 13

Interagire con tecnologie digitali: la mappatura strutturata di un processo è la competenza che separa chi usa l'AI in modo consapevole da chi la usa in modo impulsivo. La trasparenza sul funzionamento del sistema è un requisito dell'AI Act per i sistemi ad alto rischio.

Attività — Completamento Compila la scheda di mappatura per un processo dato

Leggi la descrizione del processo qui sotto, poi compila i campi della scheda. Non ci sono risposte univoche: l'obiettivo è verificare che tu abbia identificato tutti gli elementi rilevanti.

Il processo: ogni venerdì pomeriggio, il responsabile di un piccolo e-commerce controlla manualmente tutte le recensioni negative (1-2 stelle) ricevute durante la settimana su Google Business e Trustpilot. Per ciascuna, scrive una risposta personalizzata, aggiorna un foglio Excel interno con la data, il problema segnalato e la risposta data, e — se il problema è relativo a un ordine specifico — apre un ticket nel sistema di assistenza.
Lezione 2 di 3
Sezione 1 di 4

Perché la fattibilità non è solo tecnica

Quando si parla di fattibilità di un agente AI, il pensiero va subito alle integrazioni: "il tool si connette con il mio CRM?", "posso accedere ai dati in tempo reale?". Queste sono domande legittime, ma non sono le più critiche. I progetti di automazione falliscono più spesso per ragioni organizzative che tecniche.

I dati sono disponibili ma non strutturati. Il processo esiste sulla carta ma viene eseguito in modo diverso da persona a persona. Le eccezioni sono più frequenti di quanto sembri. Il responsabile del processo cambia ogni sei mesi. Questi fattori rendono un agente difficile da costruire e da mantenere, indipendentemente dalla qualità degli strumenti no-code disponibili.

La checklist di fattibilità che userai in questa lezione copre entrambe le dimensioni: tecnica e organizzativa.


Sezione 2 di 4

I rischi reali dell'automazione no-code

Ogni automazione introduce nuovi rischi insieme ai vantaggi. Ignorarli in fase di progettazione non li elimina — li sposta al momento peggiore, quello in cui l'agente è già in produzione e sta gestendo processi reali con clienti reali.

Categoria di rischio Descrizione Esempio concreto Contromisura standard
Dati sensibili L'agente accede o trasmette dati personali, fiscali o riservati senza le garanzie necessarie Agente che invia email con dati fiscali del cliente usando un template con variabile errata Test su dati anonimi, verifica GDPR delle integrazioni, log di ogni trasmissione
Errori a cascata Un errore in un nodo del workflow si propaga agli output successivi senza che nessuno se ne accorga Agente che classifica male una richiesta → risposta sbagliata inviata → ticket aperto sul cliente sbagliato Checkpoint di verifica tra i nodi, log degli output intermedi, alert su anomalie
Dipendenza dal tool Il workflow smette di funzionare se un servizio connesso cambia API, prezzi o funzionalità Make aggiorna le sue integrazioni → il nodo Gmail smette di funzionare → nessuno se ne accorge per tre giorni Monitoring attivo, notifica di errore via email o Slack, procedura manuale di backup
Input fuori schema L'agente riceve un input che non rientra nei casi previsti nelle istruzioni Email di reclamo in lingua straniera → agente non riesce a classificarla → la ignora Istruzione esplicita di fallback: "se non riesci a classificare, manda al referente del processo"

Sezione 3 di 4

Dove il processo deve restare umano

Non esiste un agente AI che debba gestire tutto da solo, senza mai coinvolgere una persona. Anche i processi più standardizzati hanno momenti in cui il giudizio umano è non solo utile ma necessario — per ragioni etiche, legali o semplicemente di qualità.

Identificare questi momenti in anticipo è parte integrante della progettazione dell'agente, non un ripensamento successivo. L'AI Act europeo li chiama "punti di supervisione umana significativa" e li richiede esplicitamente per i sistemi ad alto rischio. Ma anche per sistemi a rischio basso, definire dove l'umano entra in gioco è una buona pratica che protegge l'organizzazione e i suoi clienti.

  • Decisioni con conseguenze legali o contrattuali — firma di un documento, accettazione di un mandato, approvazione di un preventivo vincolante.
  • Comunicazioni sensibili o emotivamente cariche — risposta a un reclamo grave, comunicazione di un problema al cliente, gestione di una situazione di crisi.
  • Output che non può essere corretto dopo l'invio — email massiva, notifica a sistema esterno, registrazione contabile.
  • Eccezioni non previste nelle istruzioni — qualsiasi caso che l'agente segnala come "non classificabile" o "fuori perimetro".
Principio guida

Progetta l'agente partendo da dove vuoi che l'umano rimanga, non da dove puoi toglierlo. Questo approccio produce sistemi più sicuri e più facili da far accettare al team.


Sezione 4 di 4

Checklist di fattibilità per processi no-code

Prima di dichiarare un processo "pronto per l'automazione" e passare al Modulo 2, verifica i dodici punti qui sotto. Non è necessario che tutti siano soddisfatti al 100%, ma ogni punto non soddisfatto è un rischio da gestire consapevolmente nella progettazione.

Il processo si ripete con schema costante almeno 5 volte a settimana o ha volume cumulativo significativo
Il trigger è identificabile e monitorabile da un tool no-code (evento, timer, cambio di stato)
Gli input sono in formato leggibile da un sistema digitale (non solo cartaceo o vocale)
L'output atteso può essere verificato oggettivamente — senza dipendere dal giudizio estetico o situazionale
Le eccezioni note sono meno del 20% dei casi totali e hanno un percorso alternativo definibile
I dati trattati non richiedono garanzie speciali (es. dati sanitari, giudiziari) senza adeguata configurazione privacy
Tutti gli strumenti coinvolti hanno un connettore disponibile su Make, n8n o Zapier
Esiste una persona responsabile del processo che può validare le istruzioni dell'agente prima del deploy
Il processo è documentato o documentabile — non vive solo nella testa di una persona
Sono stati identificati i punti di supervisione umana obbligatoria prima di output critici
È possibile testare l'agente su un sottoinsieme controllato di casi prima del deploy completo
Esiste una procedura manuale di backup in caso l'agente smetta di funzionare

Punti verificati: 0 / 12

Prompt pronto all'uso
Analisi dei rischi per un processo candidato
Sto valutando di automatizzare questo processo con un agente AI no-code: [descrizione del processo con trigger, input e output]

Identifica i principali rischi nelle categorie seguenti: dati sensibili o GDPR, possibilità di errori a cascata, dipendenza da tool esterni, casi di input anomalo non previsti. Per ciascun rischio, proponi una contromisura concreta realizzabile con strumenti no-code. Infine, indica se ci sono elementi del processo che dovrebbero restare obbligatoriamente sotto il controllo di una persona.
DigComp 2.2 — Area 4.2 AI Act — Artt. 9, 14

Proteggere i dati personali e la privacy: la valutazione dei rischi prima del deploy è un obbligo implicito per chiunque utilizzi sistemi AI che trattano dati di terzi, e un requisito esplicito dell'AI Act per i sistemi classificati ad alto rischio.

Attività — Analisi di caso Identifica i rischi e le lacune in un progetto di automazione

Leggi la descrizione del progetto. Per ogni domanda, scegli la risposta che ti sembra più corretta.

Il caso: un'agenzia di comunicazione decide di automatizzare l'invio dei report mensili ai clienti. L'agente viene configurato su Make: ogni primo del mese alle 9:00, raccoglie i dati di performance da un Google Sheet condiviso (uno per cliente), genera un testo di commento usando Claude e invia il report via email direttamente al cliente, in copia all'account manager. Non è previsto nessun punto di controllo da parte del team prima dell'invio. I dati nel Google Sheet vengono aggiornati dai clienti stessi, che hanno accesso in scrittura.
1. Qual è il rischio principale di questa configurazione?
Il tool Make non supporta Google Sheets come trigger
I clienti possono modificare i propri dati nel foglio, alterando i report inviati agli altri o inserendo dati errati che vengono commentati automaticamente
L'agente non è in grado di generare testi in italiano
Il report viene inviato troppo presto nel mese
2. Quale contromisura risolve il problema senza eliminare l'automazione?
Eliminare l'accesso dei clienti ai Google Sheet e usare form separati per la raccolta dati
Posticipare l'invio automatico al 15 del mese
Aggiungere un nodo di revisione: il report generato viene inviato prima all'account manager per approvazione, poi al cliente solo dopo conferma esplicita
Sostituire Google Sheets con un database interno non accessibile dai clienti
3. Questo processo supera la checklist di fattibilità?
Sì — il volume è alto, il trigger è automatico, l'output è verificabile
Parzialmente — fallisce sul punto del controllo degli input e sul controllo da parte del team prima di output critici inviati a clienti
No — i report mensili non hanno volume sufficiente per giustificare l'automazione
Lezione 3 di 3 Modulo 2: Scrivi le istruzioni →

© 2025 AI ADOPT™ — Tutti i diritti riservati.