Come scegliere il primo processo AI in azienda: matrice di priorità ed esempio
- Processi e workflow
- 25 agosto 2026
- 9 min di lettura
- Lucia Cenetiempo
- AI Advisor, DOABLE
Cerca un’attività ricorrente, con un problema osservabile, fonti accessibili, un responsabile interno e un risultato misurabile. Una scorecard in cinque punti e un esempio per confrontare i candidati.
Se devi scegliere il primo processo AI da portare in azienda, cerca un’attività ricorrente, con un problema osservabile, dati o fonti accessibili, un responsabile interno e un risultato che puoi misurare. Il progetto diventa più gestibile quando il perimetro è circoscritto e gli errori possono essere individuati prima di produrre conseguenze rilevanti.
Quando in azienda parte una discussione sull’intelligenza artificiale, la conversazione arriva rapidamente agli strumenti.
Copilot o ChatGPT? Gemini? Un assistente interno? Un agente? Vale la pena sviluppare qualcosa di proprietario?
È comprensibile. I tool sono visibili, acquistabili e facili da confrontare. Il processo che dovrebbe migliorare rimane spesso molto più sfocato.
I dati italiani raccontano bene questa distanza. Secondo Istat, nel 2025 il 16,4% delle imprese con almeno 10 addetti utilizzava almeno una tecnologia di intelligenza artificiale, il doppio rispetto all’anno precedente. L’Osservatorio Artificial Intelligence del Politecnico di Milano rileva che l’84% delle grandi aziende aveva già acquistato licenze di Generative AI, mentre solo una su cinque dichiarava un utilizzo pervasivo dell’AI in più funzioni aziendali.
Avere accesso alla tecnologia, quindi, dice poco su quanto questa sia entrata davvero nel lavoro.
La scelta importante arriva prima: su quale processo vale la pena lavorare per primo?
Che cosa intendiamo per “primo processo AI”
Per primo processo AI intendiamo una sequenza di lavoro già esistente, con persone, input, passaggi e risultati identificabili, nella quale l’AI può modificare uno o più passaggi in modo verificabile.
Può essere, per esempio, la preparazione di un’offerta commerciale, la ricerca di informazioni in documenti tecnici, la classificazione delle richieste dei clienti, la preparazione di un report periodico o la gestione di una parte dell’onboarding.
“Usare ChatGPT nel commerciale” è ancora troppo ampio.
“Preparare la prima bozza delle offerte tecniche utilizzando esclusivamente informazioni provenienti dal CRM, dal catalogo prodotti e dalle offerte approvate” descrive già qualcosa che possiamo osservare, testare e misurare.
Questa differenza conta perché il valore dell’AI emerge dentro il lavoro reale: chi fa cosa, quante volte lo fa, quanto tempo impiega, quali informazioni utilizza, dove si verificano errori e chi controlla il risultato.
È anche il principio alla base del metodo DOABLE: partire dal lavoro che esiste oggi, individuare una priorità e costruire da lì il cambiamento.
1. Cerca un valore operativo che puoi osservare
La prima domanda riguarda il problema.
Qualcosa oggi deve richiedere troppo tempo, creare troppe revisioni, generare errori, rallentare una risposta oppure dipendere eccessivamente dalla conoscenza di poche persone.
“Vogliamo essere più innovativi” offre poco materiale per valutare un progetto.
“Ogni offerta tecnica richiede in media quattro passaggi tra commerciale e ufficio tecnico” è già un punto di partenza.
Ancora meglio se conosci la situazione attuale: tempo medio, numero di revisioni, volume mensile, errori frequenti, persone coinvolte.
Questi dati costituiscono la baseline, cioè il riferimento con cui confronterai il nuovo workflow.
2. Guarda frequenza e volume
Un’attività che richiede tre ore una volta all’anno può essere fastidiosa e avere scarso valore come primo progetto.
Una che richiede venti minuti e viene eseguita duecento volte al mese può diventare molto più interessante.
La frequenza serve anche per un altro motivo: genera casi.
Per capire se un workflow AI funziona servono esempi normali, casi difficili, input incompleti ed eccezioni. Un processo ricorrente permette di costruire più velocemente un set di test rappresentativo.
La frequenza, da sola, resta insufficiente. Un’attività molto frequente e completamente caotica può richiedere prima una revisione del processo. Allo stesso modo, un’attività già risolta bene da una semplice regola, una formula o un’automazione tradizionale potrebbe avere poco bisogno di AI.
La domanda utile diventa quindi: quante volte accade questo lavoro e quanto pesa, complessivamente, sull’operatività?
3. Verifica subito dati, documenti e fonti
Molti progetti promettenti si fermano qui.
Il team individua un ottimo caso d’uso, prepara una demo e scopre successivamente che i documenti necessari sono sparsi tra cartelle personali, SharePoint, email e software diversi. Oppure che alcuni dati sono accessibili soltanto a determinate persone. Oppure ancora che nessuno sa quale versione di un documento faccia fede.
Prima di scegliere il processo, prova a rispondere a domande molto concrete.
- Da dove arrivano oggi le informazioni necessarie?
- Chi può accedervi?
- Esiste una fonte considerata ufficiale?
- Ci sono esempi reali utilizzabili durante il test?
- Le informazioni sono sufficientemente aggiornate?
- Possiamo usarle nell’ambiente tecnologico previsto?
Qui emerge spesso una decisione importante: l’azienda può avere un buon caso d’uso AI e non essere ancora pronta a implementarlo.
In quel caso il primo lavoro riguarda fonti, accessi o qualità del dato.
Anche questa è una decisione utile.
4. Valuta cosa succede quando l’AI sbaglia
Ogni workflow AI introduce una domanda che nelle demo viene spesso trattata troppo velocemente:
Quanto costa un errore?
“Costo” può significare denaro, tempo, reputazione, rilavorazione, problemi contrattuali, impatto sul cliente o conseguenze più serie.
Un errore nella classificazione interna di un documento, se intercettabile in pochi secondi, ha caratteristiche molto diverse da un’informazione tecnica errata inviata direttamente a un cliente.
Per il primo progetto conviene cercare un processo nel quale il risultato possa essere verificato e l’errore sia gestibile.
Questo permette anche di progettare meglio la supervisione umana. Alcuni output possono essere controllati a campione. Altri richiedono approvazione prima dell’utilizzo. Altri casi meritano di essere esclusi dal perimetro iniziale.
Il NIST AI Risk Management Framework suggerisce proprio di collegare il contesto d’uso ai rischi, misurare il comportamento del sistema e stabilire come gestire le conseguenze individuate. Il framework include tra gli elementi da documentare benefici attesi, costi degli errori, ambito di applicazione e supervisione umana.
Il rischio, quindi, va valutato mentre scegli il processo.
5. Trova un owner prima di iniziare
Ogni processo ha bisogno di qualcuno che possa dire:
- “Questo output va bene.”
- “Questo caso è un’eccezione.”
- “Questa fonte è quella corretta.”
- “Questo passaggio può cambiare.”
- “Questa procedura deve restare così.”
Quella persona è il process owner.
Può essere un responsabile commerciale, il responsabile Operations, un bid manager, una persona dell’amministrazione o chiunque abbia una conoscenza sufficiente del lavoro e l’autorità per prendere decisioni sul processo.
Serve poi la disponibilità delle persone che quel lavoro lo eseguono davvero.
Un progetto AI costruito esclusivamente intorno alla visione del management rischia di scoprire troppo tardi decine di piccoli passaggi, eccezioni e workaround conosciuti solo dagli operatori.
La tecnologia può essere configurata rapidamente. Capire il lavoro richiede accesso alle persone che lo conoscono.
6. Chiarisci budget e percorso decisionale
Anche un piccolo pilot richiede risorse.
Ci sono costi tecnologici, tempo delle persone, eventuale consulenza, configurazione, test, formazione e manutenzione successiva.
Per questo nella scelta del primo processo va considerato anche il percorso con cui l’azienda può decidere di investire.
Esiste un budget? Chi può approvarlo? IT deve validare uno strumento? Procurement deve coinvolgere un nuovo fornitore? Legal o DPO devono verificare alcuni aspetti? Quanto tempo possono dedicare le persone coinvolte?
Sono elementi molto meno affascinanti di una demo.
Sono anche quelli che determinano quante demo diventano realmente un modo di lavorare.
La scorecard DOABLE per scegliere il primo processo AI
Per una prima scrematura puoi assegnare da 0 a 2 punti a cinque condizioni operative.
| Dimensione | 0 punti | 1 punto | 2 punti |
|---|---|---|---|
| Sponsor | Nessuno sponsor identificato | Interesse di un responsabile, mandato ancora debole | Sponsor identificato e in grado di sbloccare il progetto |
| Problema osservabile | Esigenza generica | Problema conosciuto, dati ancora parziali | Problema ricorrente con esempi e baseline misurabile |
| Accessi | Fonti o sistemi indisponibili | Accesso parziale o da autorizzare | Casi, fonti e strumenti accessibili in modo autorizzato |
| Persone | Nessun owner o tempo disponibile | Persone individuate, disponibilità limitata | Owner e utenti coinvolgibili nel test |
| Budget e decisione | Nessun budget o iter conosciuto | Budget plausibile, decisione da chiarire | Budget e percorso di approvazione identificati |
Il massimo è 10.
Come soglia operativa iniziale, 7/10 può indicare un candidato interessante per un pilot, purché sponsor e accessi siano presenti. È una regola di lavoro, da adattare al contesto aziendale, e non un benchmark universale.
Il punteggio serve soprattutto a rendere visibili i motivi della scelta.
Due processi con lo stesso totale possono avere condizioni completamente diverse.
Un 7/10 con dati accessibili e rischio contenuto racconta una situazione. Un 7/10 con accessi bloccati racconta tutt’altra storia.
Esempio: tre possibili processi, quale scegliamo?
Immaginiamo un’azienda B2B di circa 200 persone che sta valutando tre iniziative. L’esempio è dimostrativo e serve esclusivamente a mostrare come utilizzare la matrice.
| Processo candidato | Sponsor | Problema | Accessi | Persone | Budget | Totale | Lettura |
|---|---|---|---|---|---|---|---|
| Preparazione delle offerte tecniche | 2 | 2 | 2 | 2 | 1 | 9/10 | Ottimo candidato |
| Assistente interno per tutta la knowledge aziendale | 1 | 1 | 1 | 1 | 1 | 5/10 | Perimetro ancora troppo ampio |
| Previsione della domanda | 2 | 2 | 0 | 1 | 2 | 7/10 | Accesso e qualità dei dati bloccano il pilot |
La preparazione delle offerte emerge come primo candidato.
Il processo avviene frequentemente, esistono documenti precedenti, commerciale e ufficio tecnico possono partecipare e il risultato è facilmente verificabile prima dell’invio al cliente.
A questo punto il progetto può diventare ancora più piccolo.
Per esempio: una sola tipologia di offerta, una famiglia di prodotti, un set definito di fonti e venti casi storici su cui confrontare il nuovo workflow con il processo attuale.
L’assistente sulla knowledge aziendale può avere valore, ma richiede ancora troppe decisioni su fonti, autorizzazioni, utenti e perimetro.
La previsione della domanda ottiene persino 7 punti. L’assenza di dati utilizzabili costituisce però un blocco concreto. Partire da lì significherebbe trasformare il primo progetto AI in un progetto di sistemazione dei dati.
La matrice serve esattamente a far emergere queste differenze.
Un punteggio alto non basta: controlla i fattori bloccanti
Prima del via libera, vale la pena fare un ultimo controllo.
Un processo può sembrare molto interessante e avere contemporaneamente una condizione che rende prematuro il progetto: dati inaccessibili, responsabilità indefinita, rischio elevato, assenza delle persone che dovranno usarlo, dipendenze tecniche fuori scala rispetto al pilot.
La priorità nasce quindi dall’incrocio tra valore e possibilità reale di esecuzione.
È anche il motivo per cui un buon assessment può concludersi con la decisione di preparare prima alcune condizioni oppure rinviare un progetto.
Quando conviene rimandare il primo progetto AI
Ci sono situazioni nelle quali il progetto ha più probabilità di funzionare qualche mese dopo.
Succede quando il processo cambia continuamente e nessuno riesce a descriverlo con sufficiente chiarezza. Quando le fonti principali sono incomplete o inaffidabili. Quando manca una persona responsabile del risultato. Quando l’accesso ai dati resta incerto. Quando il beneficio atteso è talmente generico da rendere impossibile capire se il test abbia funzionato.
Può succedere anche quando esiste già una soluzione molto più semplice.
Se il problema può essere risolto con una regola, una modifica alla procedura o un’automazione deterministica, quella strada merita di essere valutata.
L’obiettivo rimane migliorare il lavoro. L’AI è una delle leve disponibili.
Dal processo al pilot
Una volta scelto il candidato, il lavoro diventa molto più concreto.
Serve descrivere il processo attuale, raccogliere una baseline, selezionare casi rappresentativi, stabilire quali fonti possono essere utilizzate, progettare il nuovo workflow, definire i controlli e decidere quali risultati renderebbero il pilot accettabile.
A quel punto si può anche scegliere la tecnologia.
La sequenza evita di chiedere a un software di inventarsi il problema che dovrebbe risolvere.
Se in azienda avete già diversi casi d’uso sul tavolo e faticate a capire da quale partire, il nostro AI Readiness & Opportunity Assessment serve proprio a trasformare processi, vincoli e idee sparse in una priorità e in una roadmap a 90 giorni.
Fonti utilizzate
- Istat, Imprese e ICT – Anno 2025, pubblicato il 15 dicembre 2025.
- Osservatorio Artificial Intelligence del Politecnico di Milano, Il mercato dell’AI in Italia cresce del 50% nel 2025, febbraio 2026.
- National Institute of Standards and Technology, AI Risk Management Framework 1.0 e AI RMF Playbook.
Domande frequenti
Le domande che ci fanno più spesso su questo tema.
Conviene iniziare da un processo ricorrente, circoscritto e osservabile. Devono esistere un problema riconoscibile, esempi reali, fonti accessibili, una persona responsabile e un risultato misurabile. Per un primo pilot sono particolarmente utili attività nelle quali gli output possono essere verificati prima di produrre conseguenze rilevanti.
Parti da più processi candidati e confrontali con gli stessi criteri. Valuta sponsor, problema osservabile, accesso a dati e fonti, disponibilità delle persone e budget. Aggiungi una verifica specifica sul rischio degli errori e sulle conseguenze del nuovo workflow. Una matrice comune rende la decisione più leggibile rispetto a una raccolta di idee basata sull’entusiasmo per singoli strumenti.
Un buon candidato ha volume sufficiente, passaggi ripetitivi, input riconoscibili e un output verificabile. Preparazione di documenti, ricerca della conoscenza, classificazione di richieste, reporting e supporto alla preparazione di offerte possono avere queste caratteristiche. La scelta dipende comunque dal processo specifico, dalle fonti disponibili e dall’impatto degli errori.
Per una prima selezione, tre-cinque processi sono spesso sufficienti per creare un confronto utile. Analizzare decine di possibilità può rallentare la decisione. Conviene partire dai problemi già visibili nell’operatività e approfondire solo i candidati che combinano valore, fattibilità e condizioni organizzative adeguate.
Conviene rimandarlo quando mancano dati o fonti affidabili, accessi autorizzati, un owner del processo, persone disponibili per i test o un risultato misurabile. Anche processi instabili e casi con conseguenze dell’errore difficili da controllare richiedono maggiore preparazione. In questi casi sistemare prima le condizioni operative aumenta la qualità del pilot successivo.
