Primo pilot AI: come scegliere l'use case giusto senza bruciare budget e fiducia

Il primo pilot AI si sceglie su due criteri secchi: alto valore di business, alta fattibilita' tecnica e organizzativa. Tutto il resto - moonshot affascinanti, vetrine da consiglio, esperimenti del singolo reparto - va parcheggiato. Sbagliare il primo use case non e' un incidente tattico: blocca il programma AI per 12-18 mesi, perche' il CdA smette di firmare assegni e i reparti perdono fiducia nel CIO.

Lo scrivo dopo aver visto una decina di programmi AI in aziende Mid-Cap del Centro-Nord (Finance, InsurTech, manifatturiero strutturato) prendere la strada giusta o sbagliata proprio nel primo trimestre. Questo articolo e' la versione lunga del framework che applico nei mandati Fractional: errori classici, matrice di prioritizzazione con scoring a 6 dimensioni, 5 categorie di use case ad alto rendimento, regola dei 90 giorni, build vs buy, metriche per il CdA. Niente buzzword.

Perche' il primo pilot AI ha un peso politico sproporzionato

In azienda esistono due narrative parallele sull'AI. La narrativa del CIO: "l'AI e' una capability infrastrutturale, va costruita per gradi, con governance e investimenti pluriennali". La narrativa del CdA: "abbiamo letto McKinsey e BCG, vogliamo risultati concreti entro l'anno, altrimenti il budget AI va su altri capitoli". Il primo pilot e' il punto in cui queste due narrative si scontrano.

Se va bene, il CdA assegna piu' budget, il CIO ottiene legittimazione, si apre la finestra per il secondo e terzo pilot. Se va male - o se resta in stallo per 9 mesi senza go-live - il CdA dichiara "abbiamo provato, non funziona", il budget viene tagliato, il programma rallenta per 12-18 mesi. Il rapporto McKinsey State of AI documenta da anni il divario tra aziende che "sperimentano con l'AI" e aziende che "catturano valore misurabile"; la ricerca MIT Sloan sull'AI-Powered Organization conferma lo stesso schema. Il salto avviene quando il primo pilot produce ROI verificabile entro l'anno fiscale. Non basta la PoC tecnica: serve un sistema vivo in produzione, con utenti reali e numeri da mostrare in CdA.

I 4 errori classici della scelta del primo use case

Framework di prioritizzazione: matrice 2x2 e scoring a 6 dimensioni

Il primo livello di selezione e' una matrice 2x2 classica - valore di business sull'asse verticale, fattibilita' sull'asse orizzontale. La regola operativa e' brutale: il primo pilot vive solo nel quadrante in alto a destra (alto valore, alta fattibilita'). Niente moonshot in alto a sinistra. Niente esperimenti facili ma marginali in basso a destra. Niente lottery ticket in basso a sinistra.

Il secondo livello e' lo scoring a 6 dimensioni. Per ogni candidato use case assegno un punteggio 1-5 su queste sei voci, le sommo, e tengo solo i top 2-3 per il deep dive:

Un use case che totalizza meno di 20 punti su 30 e' candidato debole. Sopra i 24 punti e' un candidato forte. I quattro punti centrali - tra 20 e 24 - sono la zona dove serve il giudizio direzionale, non solo lo scoring. E' il momento in cui un Fractional IT Director esterno aggiunge piu' valore: portare la prospettiva di chi ha visto altri pilot finire bene o male.

Le 5 categorie di use case ad alto valore e alta fattibilita' per Mid-Cap

Dopo decine di scoring fatti su clienti reali, questi sono i 5 archetipi che tornano sistematicamente in alto a destra nella matrice. Non sono ricette pronte: sono famiglie di use case da declinare sul contesto. Per ognuno indico tipologia di azienda dove si applica meglio e una stima realistica di ROI a 12 mesi.

1. Customer support augmentation (interno, non sostitutivo) - copilot per operatori di primo livello che suggerisce risposte basate su knowledge base e ticket storici. L'operatore valida, il cliente vede una risposta umana. Riduzione tempo medio per ticket: 20-35%. Adatto a Finance, InsurTech, Utility, e-commerce strutturato.
2. Document intelligence - estrazione automatica di dati strutturati da documenti non strutturati (contratti, perizie, polizze, fatture fornitori, ordini cliente). ROI medio: 3:1 entro 12 mesi quando il volume supera le 2-3 mila pagine/mese. Adatto a Insurance, Finance, manifatturiero con back-office documentale pesante.
3. Anomaly detection su processi e fraud - identificazione di pattern anomali su transazioni, sinistri, ordini, qualita' produzione. Funziona se esiste gia' uno storico di almeno 12-24 mesi di dati etichettati. Adatto a Finance, Insurance, manifatturiero di precisione.
4. Sales enablement - generazione di proposte commerciali, sintesi account, prep di meeting basata su CRM e dati storici. Riduzione tempo preparazione meeting: 30-50%. Adatto a B2B con cicli di vendita medio-lunghi e venditori che spendono il 40%+ del tempo in preparazione.
5. Knowledge management interno - chatbot RAG su documentazione interna (policy, procedure, manuali, tecnico). Risolve il problema "nuovo arrivato che non trova le informazioni" e "esperto che spreca tempo a rispondere alle stesse domande". Adatto a tutte le Mid-Cap con oltre 200 dipendenti e knowledge base distribuita.

Esempio recente dal campo: una compagnia InsurTech aveva selezionato come primo pilot un chatbot AI customer-facing per gestione sinistri auto. Use case di categoria 1 ma in modalita' "customer-facing" non "augmentation interna". Dopo 7 mesi e 220 mila euro, pilot chiuso: accuratezza non sufficiente per il pubblico, complaint operativi, sponsor di CdA bruciato. Sei mesi dopo la stessa azienda ha rifatto la scelta partendo da un document intelligence interno sulle perizie. Go-live in 11 settimane, ROI atteso 3:1 entro l'anno, adozione 78% degli operatori target a 90 giorni. Stesso budget complessivo, esito opposto.

La regola dei 90 giorni: cosa deve essere vivo entro 3 mesi

90 giorni dalla kickoff al go-live in produzione su un perimetro ristretto. E' la finestra entro cui un pilot mantiene la sponsorship politica iniziale. Oltre, il programma perde momentum, il CdA cambia priorita', i KPI trimestrali ridiventano dominanti, il pilot scivola in fondo alla lista.

Punto chiave: go-live in produzione, non MVP esteso. Un pilot di 90 giorni deve avere utenti reali che lo usano nel loro lavoro reale, anche se solo 5 persone su un singolo flusso. Non e' una demo, non e' una sandbox, non e' una PoC interna. E' un sistema vivo, monitorato, con metriche di utilizzo che salgono settimana dopo settimana. Cosa serve per rispettare i 90 giorni: scope severo (un solo processo, un solo team, un solo dato), tecnologie standard quando possibile, un product owner full-time o quasi, team dedicato di 3-5 persone, governance leggera con review settimanale.

Il Gartner Hype Cycle for AI mostra da anni come la fase di disillusione si attivi proprio nei programmi che restano fermi al PoC oltre i 6 mesi. La barriera dei 90 giorni e' un anticorpo strutturale a quella disillusione.

Vendor selection: build, buy o hybrid in 3 criteri secchi

La domanda "lo costruiamo o lo compriamo?" arriva sempre nelle prime due settimane. La mia regola operativa, valida per il primo pilot:

• Criterio 1 - commodity vs proprietario. Se l'use case e' una commodity di mercato (document intelligence standard, customer support generico, knowledge base RAG), buy. Esistono prodotti maturi a costo inferiore di qualunque build interno. Se invece il dato e' proprietario e il processo e' differenziante, valuta hybrid (build sopra modelli pre-trained, fine-tuning mirato).
• Criterio 2 - capability AI engineering interna. Se non hai un team con almeno 2-3 persone senior di AI engineering, il build puro al primo pilot e' una scommessa: rischi 6 mesi di setup infrastrutturale prima di vedere il primo output. Per il primo pilot e' quasi sempre meglio comprare e poi internalizzare progressivamente.
• Criterio 3 - lock-in tollerabile. Comprare un prodotto significa accettare un certo lock-in: dati nel loro formato, integrazioni nel loro ecosistema, roadmap che decide qualcun altro. Per il primo pilot questo lock-in e' accettabile (e' un esperimento, lo puoi sostituire). Diventa critico dal secondo pilot in poi, quando inizi a costruire un'architettura AI aziendale.

Un suggerimento direzionale: il primo pilot non e' il momento per decidere lo stack AI strategico dell'azienda. E' il momento per validare valore e adozione. Lo stack si decide al terzo pilot, quando hai dati di realta' su cosa funziona e cosa no nel tuo contesto.

Metriche del pilot success: cosa il CdA vuole vedere

Il CdA non vuole vedere accuracy del modello, F1 score o latenza di inferenza. Vuole vedere tre cose, in questa lingua:

1. ROI atteso vs reale - all'inizio del pilot scrivi un business case con il ROI atteso a 12 mesi sul perimetro pilot (es. 3:1, 240 mila euro di risparmio su 80 mila di investimento). A fine pilot mostri il ROI reale misurato sul perimetro. Se il reale e' nell'ordine di grandezza dell'atteso (40-150%), il pilot e' un successo. Se e' fuori scala in negativo, mostri perche' e cosa cambia nello scale-up.
2. Adozione effettiva - percentuale degli utenti target che usa il sistema in modo non-saltuario. Soglia di successo realistica: 60% degli utenti target attivi a 90 giorni dal go-live. Sotto il 40% si parla di pilot tecnicamente riuscito ma non scalato.
3. Impatto qualitativo - una o due metriche di outcome specifiche del processo (riduzione errori, tempo risparmiato, miglioramento NPS, riduzione churn). Devono essere misurate prima del pilot (baseline) e dopo (post). Senza baseline, non c'e' confronto, non c'e' storia da raccontare.

Una clausola operativa che inserisco in ogni mandato: il business case del pilot e' firmato dal business owner, non dal CIO. Il CIO e' responsabile di delivery, ma il valore economico atteso lo dichiara chi possiede il processo. Questa singola accortezza riduce drasticamente il rischio "il pilot funziona ma nessuno se ne assume la paternita' in CdA".

Come trasformare un pilot in programma: scale-up, pivot o kill

A 90 giorni dal go-live - quindi circa 6 mesi dalla kickoff - serve una decisione esplicita, formalizzata in CdA, su una delle tre opzioni:

• Scale-up - il pilot ha funzionato (ROI nell'ordine atteso, adozione sopra 60%, impatto qualitativo misurabile). Si estende l'use case ad altri team, geografie, varianti di processo. Il budget passa da pilot-budget a program-budget, tipicamente 2-3x.
• Pivot - il pilot ha mostrato valore ma su una dimensione diversa da quella attesa (es. era nato per ridurre tempo, ha invece ridotto errori). Si riprende il business case, si riscrive il valore atteso, si definisce un secondo pilot sullo use case ricalibrato.
• Kill - il pilot non ha prodotto evidenze di valore o l'adozione e' rimasta sotto il 30%. Si chiude formalmente, si scrive un post-mortem onesto, si capitalizza l'esperienza per la selezione del prossimo pilot. Il kill non e' una sconfitta se viene comunicato come scelta razionale: e' una sconfitta solo quando viene nascosto o annacquato.

L'errore peggiore - lo dico avendo visto piu' di una Mid-Cap caderci - e' la quarta opzione implicita: continuare il pilot indefinitamente. Tenerlo vivo in modalita' beta perenne per 18 mesi, senza scale-up ne' kill. E' il modo piu' veloce per bruciare il capitale politico del CIO e perdere il prossimo round di budget AI. Nel mio modello operativo, il primo pilot e' sempre parte di un mandato Fractional di 6-9 mesi che include sia la AI Strategy & Roadmap sia l'AI Delivery / Pilot. Quando serve testare interazioni utente complesse o training scenarios prima del go-live - tipicamente in customer support augmentation o sales enablement - uso anche arenia.it, il laboratorio AI Coach Live di Synergix, per simulazioni realistiche in ambiente protetto.

Domande frequenti