Un workshop di mezza giornata produce facilmente quaranta idee: “potremmo far scrivere i verbali all’AI”, “un assistente che risponde sui manuali”, “estrarre i dati dalle email dei fornitori”. Tutti escono dalla sala convinti che l’azienda stia per diventare AI-first. Sei mesi dopo, nella migliore delle ipotesi, è partito un progetto; nella peggiore, nessuno.
Il punto debole non è la generazione delle idee. È l’ordine — e più precisamente, cosa decide quell’ordine. La risposta istintiva è il ritorno: prima i casi che rendono di più. È la risposta che fa arenare i programmi di AI, perché l’ordine reale lo dettano due vincoli che il ritorno ignora: dove sono davvero i dati, e come la normativa classifica ciascun caso.
Quello che segue è il metodo che uso per trasformare quella lista grezza in un piano sequenziato e difendibile davanti alla direzione. La tesi è semplice: un piano di AI difendibile non è ordinato per ritorno sperato, ma per vincoli reali — normativi e di dato. È il punto in cui una norma smette di essere un adempimento e diventa una decisione di prodotto.
Prima la mappa, poi le idee
La domanda “cosa potremmo automatizzare con l’AI?” arriva sempre troppo presto. La fattibilità di ogni caso d’uso dipende da una cosa sola: dove sono i dati e come ci si arriva. Un assistente che risponde sui manuali è banale se i manuali sono in PDF ordinati, quasi impossibile se sono sparsi su dischi disordinati e in teste di persone.
Per questo il lavoro non parte dalle idee ma da un censimento: quali software sono in uso, quali espongono API o export, dove risiede fisicamente ogni dato, quali licenze e strumenti AI l’azienda ha già pagato senza usarli. È un lavoro poco entusiasmante e decisivo. Senza, ogni stima di costo e di fattibilità è un numero inventato.
Da qui discende il primo principio operativo: si parte da ciò che è già in casa. Massimizzare il valore degli strumenti e delle licenze già presenti, prima di proporre nuovi acquisti, evita di costruire il piano su fondamenta che ancora non esistono.
Le idee non sono tutte diverse
Quaranta idee sembrano quaranta problemi distinti. Non lo sono. Sotto la superficie, ricadono in un numero ristretto di schemi tecnici ricorrenti: un copilota che redige bozze su un corpus di documenti, un agente che risponde su una base di conoscenza, un’automazione che reagisce a un evento, l’estrazione di dati da input non strutturati con un controllo umano prima della scrittura, l’integrazione in lettura e scrittura con i gestionali.
Riconoscere lo schema di ciascun caso è ciò che cambia tutto. Permette di stimare costo ed effort per analogia con casi simili invece che da zero, e soprattutto permette di costruire la sequenza in modo che ogni schema si impari una volta sola. Il primo progetto di un certo tipo è un investimento; il secondo dello stesso tipo costa una frazione, perché l’architettura e la logica sono già state validate.
Per il CTO questa è la differenza tra un portafoglio di progetti scollegati e un’infrastruttura che si capitalizza. Per il CEO è la differenza tra spendere quaranta volte e spendere una volta sola per ogni capacità nuova.
Cosa decide davvero l’ordine
Quando ogni idea è descritta con lo stesso livello di dettaglio e valutata sulle stesse dimensioni — fattibilità, costo, effort interno, rischio, ritorno — diventa finalmente possibile confrontarle. Ma confrontarle non basta a ordinarle, e il criterio giusto non è “prima quelle col ritorno più alto”. L’ordine reale lo decidono i vincoli, non le preferenze: cosa la normativa permette di mettere in produzione adesso, e dove i dati esistono davvero.
C’è un vincolo che vince su tutti gli altri: le dipendenze. Un caso d’uso non può precedere ciò da cui dipende — un dato, un’integrazione, un’API — anche quando il suo ritorno sembra migliore. È l’errore più comune dei piani fatti col foglio di calcolo ordinato per ROI decrescente: mettono in cima qualcosa che poggia su qualcosa che ancora non c’è.
Dentro questi vincoli, quattro principi regolano la meccanica fine dell’ordine: valore visibile in settimane e non in mesi, perché i primi risultati costruiscono la fiducia interna che rende possibili le fasi difficili; complessità tecnica crescente, da ciò che si fa senza sviluppo custom verso le integrazioni vere; riuso a ogni onda di quanto costruito nella precedente; rischio per ultimo, con i casi ad alto impatto legale o su dati sensibili che entrano solo quando il team ha esperienza e le misure di governance sono in essere. Sono la meccanica, non il motore: il motore restano i due vincoli.
La regolazione decide la sequenza, non la subisce
Ogni caso d’uso di AI ha una collocazione nell’EU AI Act: dalla pratica vietata, che esce dal piano, al rischio alto con i suoi obblighi pieni, fino al rischio minimo dei copiloti interni. Questa collocazione non è una verifica da fare alla fine — è il primo criterio con cui si ordina. Un caso ad alto rischio non può partire prima che siano in opera le misure di governance che richiede, per quanto attraente sia il ritorno. Uno a rischio minimo — un assistente interno sui documenti — può partire subito. È la classe di rischio, non il ROI, a decidere chi va per primo.
Lo stesso vale per i dati personali e particolari — sanitari, retributivi. Gli obblighi GDPR, la base giuridica, gli accordi sul trattamento vanno sistemati prima dell’avvio, non rincorsi dopo. Trattare AI Act e protezione dei dati come ingressi della pianificazione, e non come ostacoli da aggirare, è ciò che rende un piano difendibile invece che ottimistico. È anche il punto preciso in cui una norma diventa una decisione di prodotto: non un vincolo da subire a valle, ma il criterio che a monte disegna la roadmap.
C’è uno scalino tra “abbiamo fatto le verifiche per questo progetto” e “abbiamo un modo stabile di farle per tutti i progetti che verranno”. La ISO/IEC 42001 — la norma sui sistemi di gestione dell’intelligenza artificiale (AI Management System) — copre proprio quello scalino: trasforma la governance da controllo una tantum su un caso d’uso in un processo ripetibile sui successivi. Per il CTO significa non rifare da capo l’analisi del rischio a ogni nuovo caso; per il CEO significa poter dire, con evidenza, che l’azienda gestisce l’AI invece di limitarsi a usarla. Avendo una struttura armonizzata con gli altri sistemi di gestione, si innesta su ciò che l’azienda già ha — qualità, sicurezza delle informazioni — senza diventare un binario separato.
Il costo vero non è la somma dei costi
Stimare il budget di ogni caso d’uso in isolamento e poi sommarli sovrastima il costo reale, spesso in modo grossolano. Una licenza che serve a cinque casi d’uso si paga una volta. Un’infrastruttura — un repository ordinato, un database, un connettore — si configura una volta. Un progetto che replica uno schema già costruito costa molto meno del primo.
L’analisi seria dei costi ragiona per fase, applicando queste economie di scala, e produce una mappa delle licenze che dice non solo cosa serve, ma esplicitamente cosa non serve comprare. L’errore tipico è la licenza premium per tutti quando bastano pochi profili tecnici a costruire e molti utenti a consumare. Dire al cliente cosa non deve acquistare vale, in fiducia, più di qualunque proposta.
Il deliverable è una decisione, non un documento
Alla fine il metodo non produce un report da archiviare. Produce una sequenza: cosa parte prima, da cosa dipende, quali condizioni devono essere vere perché la fase successiva possa iniziare. Ogni passaggio tra le fasi è legato a una verifica concreta — “API confermate dal fornitore”, “classe di rischio AI Act assegnata”, “accordo sui dati firmato” — non a un’ipotesi. Un piano condizionato a verifiche regge il confronto con la direzione; un piano fatto di buone intenzioni no.
Vista da lontano, questa è una descrizione di come si gestisce l’innovazione: raccogliere idee, valutarle con criteri costanti, sequenziarle, finanziarle, presidiarle. Non è un’intuizione mia. La ISO 56001 — pubblicata nel 2024, prima norma certificabile sui sistemi di gestione dell’innovazione (Innovation Management System) — descrive esattamente questo ciclo, e l’AI è il banco di prova più concreto su cui applicarlo oggi. Per un’azienda manifatturiera è la differenza tra trattare l’AI come una serie di scommesse isolate e trattarla come una capacità che si costruisce e si misura nel tempo.
La distanza tra una lista di idee e un piano di AI non si misura in tecnologia. Si misura nella disciplina con cui si lascia decidere l’ordine ai vincoli reali — cosa la normativa permette, dove i dati esistono — invece che al ritorno sperato.