Nel mio precedente post sul report The GenAI Divide – State of AI in Business 2025 ho messo in luce alcuni punti che richiedono cautela nell’interpretazione delle conclusioni di quell’interessante lavoro. Da quelle osservazioni nasce l’idea di questo articolo: proporre una serie di linee guida pratiche per distinguere i progetti di AI con basi solide da quelli destinati a naufragare prima della produzione.
Prima di procedere, una precisazione importante: quando parlo di "progetto AI", mi riferisco specificamente allo sviluppo della componente di intelligenza artificiale, che rappresenta quasi sempre solo una tessera di un mosaico più ampio fatto di sviluppo software, infrastruttura e trasformazione organizzativa. Le indicazioni che seguono non sono dogmi, ma strumenti pragmatici per ridurre rischi e massimizzare il valore dell'AI nel contesto aziendale.
Le tre anime dei progetti AI
Per orientarci meglio, distinguiamo tre archetipi principali:
Progetti AI-Centrali (Tipo A): l'AI è il cuore pulsante del prodotto. Senza di essa, il prodotto semplicemente non esisterebbe. L'intelligenza artificiale è il cuore pulsante del prodotto. Pensate a un assistente virtuale o a un sistema di diagnosi medica da immagini radiologiche.
Progetti con AI-a-Supporto (Tipo B): l'AI agisce come acceleratore nello sviluppo di un prodotto che può anche non contenere AI. Un esempio potrebbe essere una migrazione isofunzionale di una codebase legacy verso un stack tecnologico più moderno, cioè il trasferimento di un sistema da una tecnologia obsoleta a una nuova mantenendo le stesse funzionalità, ma con strumenti più efficienti e aggiornati.
Progetti Abilitanti per l'AI (Tipo C): progetti infrastrutturali che creano le fondamenta per futuri sviluppi AI. Piattaforme dati, framework di governance, sistemi di monitoraggio.
Questo articolo si concentra sui primi due tipi, trattando il terzo come attività propedeutica con impatto indiretto. Naturalmente, la realtà presenta moltissime sfumature che sarebbe impossibile cogliere nello spazio di questo articolo. La stessa considerazione di non esaustività vale anche per tutto il prosieguo: i principi che seguono sono utili come bussola, non come mappa dettagliata.
La prima regola: dimenticatevi della tecnologia (All'Inizio)
Se state già discutendo di GPT-5 versus Claude, di RAG versus fine-tuning, o del framework da utilizzare, fermatevi. State partendo con il piede sbagliato.
Il punto di partenza corretto è un approccio consulenziale puro: concentratevi sul problema del vostro referente – che sia un cliente, uno stakeholder o voi stessi – escludendo inizialmente ogni riferimento all'AI.
Un trucco che funziona: se il vostro interlocutore ha fame di tecnologia, organizzate sessioni separate di formazione sull'AI per appagare la curiosità. Workshop, demo, sandbox dove sperimentare. Ma tenete questi momenti rigorosamente separati dalle sessioni di analisi del problema. Non permettete mai che lo studio del bisogno aziendale si trasformi in una discussione sulle capacità dei modelli o sulle architetture tecniche. Sono due conversazioni diverse che devono rimanere tali. Questa disciplina è fondamentale perché, senza di essa, l'analisi dei bisogni devia inevitabilmente verso discussioni tecniche premature che offuscano la vera natura del problema.
Due verità scomode da tenere sempre presenti:
- Un processo efficiente con risorse umane raramente è pronto per l'AI senza profonde revisioni
- Un processo già digitalizzato non si presta automaticamente all'integrazione AI, nonostante sia "già nel computer"
L'obiettivo è comprendere profondamente il contesto operativo, resistendo al canto delle sirene tecnologiche.
Due domande che predicono il successo
Domanda 1: "Qual è il Business Case quantificato?"
Nei progetti di tipo A, il vostro interlocutore deve aver già misurato lo stato attuale con precisione chirurgica. Quanto costa oggi, senza AI, ottenere quel risultato? Quanto tempo richiede? Quante persone sono coinvolte? Quali sono i punti di frizione?
Campanello d'allarme: se la prima preoccupazione è "quanto costa un modello LLM al token", probabilmente il vostro referente non ha le competenze o il mandato per costruire un vero business case. È un sintomo tipico di progetti nati da rielaborazioni IT di problemi di business – si parte dalla soluzione tecnologica invece che dal valore aziendale. Aprite canali di comunicazione con manager di linea per una prospettiva completa. Ad esempio, un'automazione AI per un problema di business deve essere approfondita con gli esperti del business e non il dipartimento IT.
Esempio concreto: in un progetto di automazione del servizio clienti, il business case dovrebbe confrontare il tempo medio di risposta umano (diciamo 5 minuti) con i benefici potenziali derivanti da una riduzione a 1 minuto grazie all'automazione AI, includendo tutti i costi diretti e indiretti della situazione corrente. Senza questi numeri, il progetto rimarrà eternamente un "interessante pilota" – tutte le condizioni ideali per sperimentare quella GenAI Divide di cui parlavo nel post precedente.
Domanda 2: "Concretamente, sapremmo progettare questa soluzione senza AI?"
Nei progetti di tipo B, il discrimine è la vostra capacità di stimare complessità, costi e tempi indipendentemente dall'AI. L'intelligenza artificiale potrà accelerare fasi specifiche – generazione di codice, documentazione, test – ma servirà sempre un esperto umano capace di comprendere, validare e perfezionare i risultati.
Pensate a una migrazione da sistemi legacy: se non conoscete profondamente sia la tecnologia di partenza che quella di arrivo, affidarsi all'AI equivale a tradurre un testo antico usando Google Translate senza conoscere nessuna delle due lingue. Il disastro è garantito.
La metà invisibile del progetto
Ecco una verità che molti preferiscono ignorare: il 50% del tempo di un progetto AI ben strutturato si consuma prima di scegliere qualsiasi tecnologia AI.
La distribuzione tipica:
- 30% per comprendere: raccolta dei bisogni, interviste, osservazione dei processi attuali
- 20% per definire: perimetrazione del problema con dati concreti, definizione dei criteri di successo
Durante questa fase, il vostro interlocutore fornirà dati reali per validare la comprensione e delimitare i confini del progetto. Preparatevi a riaprire discussioni che sembravano chiuse – è normale e salutare.
Resistete alle pressioni per "iniziare subito con l'AI". L'obiettivo in questa fase è cristallizzare cosa deve essere fatto e come misurarne il successo, non come farlo tecnicamente.
Perché questa ossessione per la consulenza?
La GenAI ha portato l'automazione così vicina alle capacità umane che la chiarezza iniziale è diventata cruciale. Non è più sufficiente chiedersi "cosa può fare la tecnologia?". Ora dobbiamo:
- Sapere esattamente cosa deve essere fatto
- Saperlo articolare in modo operativo (per umani e macchine)
- Progettare l'orchestrazione tra intelligenze umane e artificiali
Senza questa chiarezza, rischiate di costruire una soluzione tecnicamente brillante che risolve il problema sbagliato.
Dalla teoria alla baseline
Una volta compresi bisogni e perimetro, si costruisce la baseline – il vostro primo prototipo funzionante. Qui l'AI diventa finalmente protagonista.
Obiettivi di questa fase:
- Verificare i vincoli reali – quali condizioni devono essere rispettate perché l'AI sia praticabile?
- Esplorare lo spazio delle soluzioni – testare modelli, architetture, approcci diversi senza preconcetti
- Quantificare costi e benefici – confrontare consumo di risorse e risultati con le previsioni del business case
In questa fase, l'AI può supportare lo sviluppo di soluzioni AI, fornendo insights e accelerando l'esplorazione delle opzioni.
Impegnatevi a costruire, insieme al referente, un test set che rappresenti fedelmente il problema reale e usatelo come base di riferimento, nel tempo, per condurre analisi comparate e oggettive.
I veri fattori di successo (e i segnali di pericolo)
Al 70% del percorso, il destino del progetto è solitamente segnato. Due elementi fanno la differenza:
La maturità del vostro committente: ha davvero compreso il proprio bisogno? Il business case regge a un'analisi critica?
La vostra disciplina iniziale: avete resistito alla tentazione di partire dalla tecnologia? Avete davvero capito il problema?
Segnali di pericolo da non ignorare
- Ossessione per i costi del modello: indica assenza di business case o visione puramente tecnica
- Deriva infrastrutturale: il progetto sta scivolando verso la categoria C (piattaforme abilitanti)
- FOMO tecnologico: ansia per la velocità dell'innovazione, focus sulla selezione tecnologica invece che sul problema
- Interlocutore puramente tecnico: manca il collegamento con chi vive il problema quotidianamente
Quando l'AI non serve
Alcuni esempi pratici:
- Se un processo gestito da persone funziona bene e produce risultati soddisfacenti, l'AI è probabilmente superflua
- Se il processo è percepito come inefficiente dagli operatori che lo praticano, aggiornate prima il processo, poi valutate l'AI
- Se il problema deriva da debito tecnico accumulato (codice legacy, architetture obsolete, documentazione mancante), l'AI può aiutarvi a mappare e quantificare il problema, ma non dovrebbe essere usata come cerotto per evitare la necessaria ristrutturazione. Usare l'AI per "far funzionare" sistemi mal progettati significa solo rimandare e aggravare il problema
Il bivio: produzione o abbandono
Dopo la baseline, due strade si aprono:
Il progetto si ferma: non arriverà mai in produzione. La mia speranza è che riflessioni come quelle proposte in questo post possano aiutare a ridurre questa eventualità. In ogni caso, questa situazione non è necessariamente un fallimento: può diventare un risparmio di tempo e risorse, soprattutto se la decisione arriva dopo un percorso mirato di Proof of Concept (PoC). Valutare in anticipo con un PoC se un’idea è davvero industrializzabile significa evitare di investire in iniziative senza prospettive concrete.
Il progetto prosegue: si passa all'industrializzazione. Ottimizzazione di prestazioni, resilienza, scalabilità. Entrano in gioco nuove competenze: sicurezza, infrastruttura, operations. Il progetto AI diventa un ingranaggio di una macchina più grande. Lo specialista AI deve restare focalizzato sul proprio ruolo, interagendo con gli altri attori senza farsi carico di responsabilità estranee.
Uno sguardo al domani: l'era degli Agenti
Il futuro prossimo vedrà soluzioni sempre più agentizzate: entità artificiali specializzate, distribuite come microservizi, coordinate da protocolli condivisi. Ogni organizzazione avrà il proprio "registro di competenze artificiali" – un organigramma parallelo che affianca quello umano.
Un orchestratore centrale (l'equivalente di un assistente virtuale aziendale) attiverà queste competenze secondo necessità, creando sinfonie di collaborazione tra intelligenze umane e artificiali. Il ruolo dei progettisti evolverà verso la supervisione strategica: inquadrare obiettivi, dimensionare sforzi, orchestrare risorse miste, perfezionare risultati.
Questo scenario valorizzerà l'unicità umana nelle fasi creative e strategiche, distinguendola dalle capacità generative delle macchine.
La verità finale
La GenAI non è una bacchetta magica. È un amplificatore:
- Di competenze, se usata da esperti
- Di confusione, se applicata senza metodo
- Di efficienza, se innestata su processi solidi
- Di problemi, se inserita in contesti fragili
Il successo di un progetto AI non dipende dal modello più sofisticato o dal framework più alla moda. Dipende dalla qualità della comprensione iniziale del problema e dalla disciplina nell'affrontarlo.
La domanda da porsi non è: "Cosa può fare l'AI per noi?"
La domanda giusta è: "Abbiamo davvero capito cosa vogliamo ottenere?"
Solo quando avrete una risposta cristallina a questa seconda domanda, l'AI potrà davvero fare la differenza.