AI Program Management
Program Management Progetti AI: Guida Completa
Un programma AI non fallisce quasi mai per colpa del modello. Fallisce perché nessuno ha deciso chi possiede la roadmap, quali numeri contano davvero e cosa succede il giorno dopo il rilascio del pilota. Da Program Manager AI e Trasformazione Digitale in Xister Reply ho portato iniziative di questo tipo dalla prima ipotesi fino alla produzione, allineando i vertici aziendali su cosa rilasciare e quando. In questa guida metto in fila il metodo che uso davvero: come costruire una roadmap AI credibile, come prioritizzare i casi d'uso, quale governance serve sul campo e come si misura se un programma sta funzionando oppure sta solo consumando budget.
Perché un programma AI si gestisce diversamente da un progetto IT
Un progetto IT tradizionale parte da requisiti chiusi e da un piano che, salvo imprevisti, si rispetta. Un programma AI parte da un'ipotesi su un comportamento, umano o di un modello, che potrebbe rivelarsi sbagliata. Il primo insegnamento che porto da quando gestisco questi programmi è accettare che il perimetro cambia man mano che arrivano i dati reali: un caso d'uso che sembrava prioritario in roadmap può perdere senso appena vedi come gli utenti interagiscono davvero con l'output del modello, o quanto sono incompleti i dati che dovrebbero alimentarlo.
Ho vissuto questo passaggio in prima persona. Tra il 2021 e il 2023, come AI Product Manager in Xister Reply, ho costruito soluzioni AI puntuali: il doppiaggio video multilingua per Enel, che ha ridotto del 75% il lavoro di localizzazione, e un servizio di podcast generati con AI per Toyota e Intesa Sanpaolo. Dal 2024 il mio ruolo è cambiato: non gestisco più un singolo prodotto AI, ma un intero programma che intreccia trasformazione digitale, sperimentazione e go-to-market, ognuno con la propria velocità e i propri rischi. È lì che la disciplina di program management pesa più della competenza tecnica sul singolo modello.
Dalla richiesta del board alla roadmap trimestrale
Quasi ogni programma AI parte da una richiesta vaga: "vogliamo usare l'AI su questo processo". Il lavoro del program manager è tradurla in una roadmap che il board possa davvero seguire, il che significa tagliarla in trimestri, non in un piano triennale che nessuno rispetterà.
Prima ancora di parlare di modelli, verifico che l'azienda sappia misurare il punto di partenza. Quando ho guidato la trasformazione SEO e analytics dell'e-commerce Whirlpool EMEA, il primo blocco di lavoro non riguardava l'AI in senso stretto: riguardava rimettere in ordine Google Analytics e Power BI per avere un baseline affidabile, un lavoro che ha poi portato a un +174% di traffico organico. Senza quel fondamento, qualsiasi iniziativa AI costruita sopra sarebbe stata un'ipotesi su dati inaffidabili. La roadmap trimestrale che presento ai C-level parte sempre da qui: cosa sappiamo misurare oggi, cosa vogliamo spostare nei prossimi tre mesi, e quale caso d'uso AI serve davvero a spostarlo.
Come prioritizzo i casi d'uso: valore, fattibilità, dati disponibili
Con più idee di quante risorse per eseguirle, ogni programma AI ha bisogno di un filtro esplicito. Uso tre criteri, nell'ordine in cui li verifico: il valore atteso per il business (non "fa risparmiare tempo" in astratto, ma quanto e a chi), la fattibilità tecnica nel tempo che abbiamo a disposizione, e la disponibilità reale dei dati necessari. Quest'ultimo criterio è quello che salta più spesso in fase di pianificazione, ed è quello che uccide più piloti in produzione: un caso d'uso brillante sulla carta, ma alimentato da dati incompleti o mai raccolti in quel formato, non arriva quasi mai oltre la demo.
Per stimare il valore atteso mi affido più ai dati di comportamento reale degli utenti che alle proiezioni sulla carta, un'abitudine che viene dal mio percorso in Cyberpsychology, dove ho imparato a diffidare di ciò che le persone dicono che faranno e a fidarmi di ciò che fanno davvero. Il caso Enel resta per me l'esempio migliore di cosa succede quando i tre criteri sono allineati fin dall'inizio: il doppiaggio video multilingua con AI ha portato a una riduzione del 75% dei costi di localizzazione, un risultato che nasce dall'aver verificato in anticipo che valore, fattibilità e dati fossero coerenti tra loro, invece di scoprirlo a pilota già avviato. Non tutti i casi d'uso arrivano con questo allineamento, ed è compito del program manager dirlo chiaramente al board prima di impegnare budget, non dopo un pilota fallito.
Governance operativa: decisioni, non documenti
La governance di un programma AI che funziona davvero non è una policy firmata una volta e archiviata. È un insieme di decisioni operative ricorrenti: chi possiede il modello dopo il rilascio, chi autorizza il passaggio da pilota a produzione, cosa succede quando le prestazioni scendono sotto una soglia concordata. Ho scritto altrove, in questa stessa sezione del blog, un approfondimento dedicato al RACI e ai risk gate che uso sul campo, perché il tema merita spazio a sé.
Quello che posso dire qui è che la governance si vede nella cadenza, non nel documento. Nel mio ruolo attuale ho istituito una cadenza strutturata di client success che ha fatto crescere il business ricorrente del 47%: revisioni periodiche in cui si decide esplicitamente cosa continuare, cosa fermare e cosa scalare. La stessa logica vale dentro un programma AI interno: senza un momento ricorrente in cui qualcuno con autorità decide se un'iniziativa vive o muore, i piloti restano piloti per sempre.
I KPI che dicono se il programma è vivo
Un programma AI senza KPI concordati prima del lancio è un programma che si giudicherà con il senno di poi, quando è troppo tardi per correggere la rotta. La disciplina che applico qui è la stessa che uso nei programmi di sperimentazione CRO: ogni iniziativa deve avere una metrica attesa, uno strumento per misurarla e una soglia che ne definisce il successo, decisi prima di partire.
Con Whirlpool EMEA questo ha significato collegare ogni test guidato da ipotesi a un obiettivo di conversione misurabile in Google Analytics e Power BI, arrivando a un +57% di conversione sull'intero perimetro e-commerce. Nei programmi AI applico lo stesso principio: prima di dare il via libera a un caso d'uso, voglio sapere quale numero cambierà, con quale strumento lo vedremo muoversi, e chi lo controllerà ogni settimana. Ho dedicato un articolo a parte a come strumentare questi KPI in produzione, perché il lato tecnico (log dei modelli, dashboard, alert) merita di essere trattato per esteso.
Il business case che il board approva davvero
Il board non si convince con l'architettura del modello. Si convince con un business case che lega l'investimento a un ritorno misurabile, espresso nel linguaggio con cui giudica ogni altro investimento aziendale: pipeline, margine, costo evitato. Ho costruito business case in questi termini anche fuori dal perimetro strettamente AI: il go-to-market partner-led di Optimizely che ho guidato nei primi sei mesi ha generato 1M€ di pipeline, 5 opportunità e 15 proposte, e quel risultato è nato da un business case che prometteva un numero specifico, non una tecnologia promettente.
Per un programma AI il principio non cambia: se non riesco a scrivere in una riga cosa cambierà nel conto economico o nell'esperienza cliente, e con quale margine di errore, il business case non è pronto per il board. Ho scritto separatamente come costruisco questi business case passo per passo, perché la parte di negoziazione con la finanza merita un approfondimento a sé.
Dove entrano davvero gli agenti AI nella roadmap
Gli agenti AI e i workflow agentici sono, in questo momento, la voce più rumorosa in ogni conversazione con il board. Nella pratica del program management li tratto come qualsiasi altro caso d'uso: passano dagli stessi tre filtri di valore, fattibilità e dati disponibili, e non ottengono una corsia preferenziale solo perché sono la novità del momento. Le certificazioni Microsoft in Program Management e in AI Product Management che ho conseguito nel 2025 mi servono soprattutto per questo: per resistere alla tentazione di dare priorità a un'iniziativa solo perché è agentica, e per applicare lo stesso filtro di sempre. Ho approfondito altrove quando un agente aggiunge valore reale in un processo aziendale e quando è solo un'automazione già esistente travestita da novità.
Lo stesso vale per l'AI applicata al marketing in senso più ampio: i casi Enel e Toyota/Intesa Sanpaolo che ho citato qui sono raccontati con più dettaglio, numeri e scelte tecniche incluse, nella guida che ho scritto sull'AI per il marketing, dove il focus è sugli strumenti e i workflow più che sul program management che li tiene insieme.
Cosa porto da ogni programma AI che gestisco
Se dovessi ridurre tutto questo a poche regole operative, sarebbero queste. La roadmap si costruisce sui numeri che sai già misurare, lasciando fuori quelli che vorresti avere ma non hai ancora. Un caso d'uso senza dati pronti non è pronto, indipendentemente da quanto sia convincente la demo. La governance vive nella cadenza delle decisioni, non in un documento. I KPI si concordano prima del lancio, mai dopo. Il business case, infine, parla la lingua del board (pipeline, margine, costo evitato), più che quella dell'ingegneria.
Ho applicato questo metodo a programmi molto diversi tra loro: dalla trasformazione e-commerce di Whirlpool EMEA al go-to-market di Optimizely, dal doppiaggio AI per Enel al podcast per Toyota e Intesa Sanpaolo. Il filo comune non è mai stata la tecnologia specifica, ma la disciplina con cui l'ho portata dalla roadmap alla produzione. Se stai valutando di strutturare un programma simile nella tua azienda, trovi il dettaglio di come lavoro nella sezione servizi del sito.
Parliamo del tuo progetto
Ti è utile questo articolo? Vediamo come applicarlo al tuo contesto.
Articoli correlati
Business Case per l'AI: Farlo Approvare dal Board
Come costruire un business case per l'AI che il board approva: legare l'investimento a KPI credibili e a un ritorno misurabile, non a promesse tecnologiche.
KPI di un Progetto AI: Misurare in Produzione
Quali KPI seguire per capire se un progetto AI funziona in produzione, come strumentarli e come collegarli al business case che lo ha fatto approvare dal board.
Dal PoC alla Produzione: Perché i Progetti AI Falliscono
La maggior parte dei progetti AI muore nel pilota. Cosa serve davvero per passare dal PoC alla produzione, con le lezioni imparate su casi enterprise reali.