Sempre più Project Manager e Product Owner si trovano a gestire iniziative legate all’Intelligenza Artificiale. Spesso, però, questi progetti vengono affrontati con lo stesso approccio utilizzato per lo sviluppo software tradizionale: raccolta requisiti, pianificazione, sviluppo, rilascio. È un riflesso naturale. Ma nei progetti AI questo approccio rischia di portare fuori strada molto rapidamente. Il motivo è semplice: un progetto AI non è soltanto sviluppo. È, nella sua essenza, un progetto di ricerca applicata.
E questo implica una conseguenza concreta: prima di costruire, bisogna dimostrare che esista qualcosa che valga la pena costruire.
Quando il progetto cambia davvero
Immaginiamo una situazione reale. Un’azienda decide di automatizzare la classificazione delle richieste via email dei clienti. Il backlog è chiaro, il valore è evidente, il team è pronto. Sulla carta, sembra un progetto come tanti altri. Nel software tradizionale, la domanda che guida il lavoro è:
“Come costruiamo la soluzione?”
Nel mondo AI, la domanda cambia:
“Esiste davvero una soluzione sufficientemente buona?”
Non è una sfumatura teorica. È qualcosa che emerge appena si analizzano i dati reali.
Le email dei clienti, ad esempio, potrebbero:
- essere scritte in modi completamente diversi
- contenere più richieste nello stesso testo
- essere classificate in modo incoerente nel passato
- includere casi ambigui o borderline
A quel punto, il problema non è più implementare un classificatore. Il problema è capire se i dati permettono davvero di costruirne uno affidabile. Nel software il rischio è costruire lentamente. Nell’AI il rischio è costruire qualcosa che non funzionerà mai.
La PoC: il primo vero deliverable
È qui che entra in gioco la Proof of Concept. Non come esercizio tecnico, ma come momento decisionale. Una PoC efficace non è un prototipo completo. È un esperimento mirato che risponde a una domanda precisa, ad esempio:
- “Riusciamo a raggiungere almeno il 75% di accuratezza su dati reali?”
- “Il sistema è abbastanza stabile da supportare un operatore umano?”
- “Il problema è modellabile con i dati disponibili?”
Durante questa fase succede spesso qualcosa di importante: le ipotesi iniziali vengono ridimensionate. Torniamo all’esempio.
Il team scopre che:
- alcune categorie funzionano bene
- altre sono troppo ambigue
- il modello è utile, ma non per automazione completa
A quel punto cambia la direzione: non più “automatizziamo tutto”, ma “assistiamo l’operatore”. Questo non è un fallimento. È una decisione informata, presa presto, quando il costo del cambiamento è ancora basso.
Quando il codice non basta
Nel software tradizionale, se qualcosa non funziona, si cerca un bug. Si corregge e il sistema migliora. Nei sistemi AI non è così lineare.
Se un modello sbaglia, potrebbe dipendere da:
- dati incompleti o non rappresentativi
- distribuzioni sbilanciate
- ambiguità intrinseca del problema
- mancanza di contesto
In altre parole, non sempre c’è qualcosa da correggere. A volte c’è semplicemente qualcosa da capire.
Partire piccoli per decidere meglio
Un errore comune è voler arrivare subito alla soluzione completa. Ma nei progetti AI, partire in grande spesso significa esporsi a un rischio elevato senza averlo misurato. Un approccio più efficace è quello più pragmatico.
Un team che lavora su documenti legali, ad esempio, potrebbe iniziare da:
- un solo tipo di documento
- una sola informazione da estrarre
- un dataset limitato ma reale
Dopo pochi giorni, emergono segnali chiari:
- funziona → si può estendere
- funziona parzialmente → si adatta il caso d’uso
- non funziona → si evita di scalare un errore
Questo permette al PM di prendere decisioni: continuare, pivotare o fermarsi.
Scorciatoie utili (ma non sostitutive)
Anche se una PoC o uno studio di fattibilità restano passaggi imprescindibili, esistono alcune scorciatoie che aiutano a capire rapidamente il potenziale di un’idea e possono essere utilizzate direttamente dai PM senza scomodare il team di sviluppo. Sono strumenti di orientamento, non di validazione definitiva, ma permettono di avere una prima idea di base oggettiva, rispetto alla semplice intuizione. Una delle più note è quella proposta da Andrew Ng.
Secondo questa regola empirica, se un essere umano impiega meno di un secondo per prendere una decisione, come classificare una richiesta o riconoscere un oggetto in una foto, allora è probabile che quel compito sia un buon candidato per l’automazione tramite il machine learning. Non garantisce il successo, ma aiuta a evitare casi d’uso troppo complessi nelle fasi iniziali.
Un’altra scorciatoia molto concreta oggi è l’uso dei modelli linguistici in modalità chat per una prototipazione rapidissima.
Torniamo al caso delle e-mail dei clienti.
Un Project Manager o un Product Owner potrebbe:
- prendere una decina di e-mail reali
- inserirle in una chat con un LLM
- chiedere di classificarle secondo alcune categorie
In pochi minuti emerge un primo segnale:
- il modello coglie il senso delle richieste?
- le classificazioni sono coerenti?
- gli errori sono accettabili?
Se il modello sbaglia anche nei casi più semplici, è un segnale forte: probabilmente il problema è mal definito o i dati sono critici. Se invece sbaglia solo nei casi ambigui, potrebbe già essere utile in uno scenario assistivo. Questo tipo di test non sostituisce una PoC, ma aiuta a decidere se iniziarla.
Un’altra indicazione utile emerge quando si prova una soluzione molto semplice. Se poche regole o un prompt basilare producono risultati già validi, è possibile che il problema non richieda grande complessità. Al contrario, se gli approcci su problemi semplici falliscono completamente, è un segnale precoce di rischio.
Infine, c’è un aspetto che impatta direttamente il valore del progetto: il contesto reale. Un sistema può funzionare bene su dati puliti e fallire completamente nel mondo reale, tra errori, ambiguità e casi limite. Testare presto su dati realistici è uno dei modi più economici per evitare errori costosi.
Il vero punto decisionale
Alla fine, ciò che distingue davvero un progetto AI da uno tradizionale non è la tecnologia, ma il tipo di decisioni che abilita.
Nel software: come costruiamo la soluzione?
Nell’AI: esiste una soluzione sufficientemente buona e sostenibile per il nostro contesto?
“Sufficientemente buona” significa non solo tecnicamente valida, ma anche:
- utile per il business
- economicamente sostenibile
- integrabile nei processi esistenti
Finché non si risponde a questa domanda, ogni roadmap, ogni architettura e ogni piano di sviluppo restano solo delle ipotesi; ed è esattamente qui che si gioca il successo, o il fallimento, di un progetto AI.
