Come Lanciare un Pilota AI in una PMI Italiana in 6 Settimane
Il playbook operativo per lanciare un pilota AI in 6 settimane: come scegliere il caso d'uso, piano settimana per settimana e decisione scale, pivot o stop.
Indice
Perche partire da un pilota (e non da una strategia AI)
Il peggior consiglio che un imprenditore italiano possa ricevere oggi e 'costruisci prima una strategia AI per la tua azienda'. Suona saggio, metodologico, da manuale Harvard Business Review. In pratica, e il modo piu efficace per bruciare 6-12 mesi senza produrre nulla di utile, spendere decine di migliaia di euro in workshop e documenti, e arrivare a un punto in cui il mercato e gia cambiato e la strategia e obsoleta prima ancora di essere eseguita.
Il motivo per cui le strategie AI delle PMI italiane non funzionano e strutturale. La strategia per definizione richiede conoscenza del terreno. L'AI nel 2026 e un terreno che nessuno conosce bene: non i consulenti che vendono workshop, non i software vendor, non i titolari di azienda, nessuno. Chiunque ti venda una strategia AI costruita in uno studio a tavolino sta facendo astrologia con piu slide.
La conoscenza del terreno si acquisisce in un solo modo: costruendo piccole cose reali e osservando cosa succede. Un pilota AI di 6 settimane ti insegna piu sulla realta dell'AI nella tua azienda di un anno di workshop strategici. Il secondo motivo e economico. Una strategia AI formale costa tipicamente 15-50k di consulenza senza produrre nulla di operativo. Un pilota AI costa 8-20k e produce un sistema funzionante, un apprendimento misurato sul tuo specifico contesto e una decisione go/no-go basata su dati.
A parita di budget, il pilota produce molto piu valore. Il terzo motivo e psicologico. Una strategia AI richiede committment a lungo termine prima di vedere risultati. In una PMI italiana, dove il titolare decide in base a cio che funziona e non a cio che e teoricamente corretto, il committment a lungo termine senza risultati visibili crolla dopo tre mesi. Il progetto muore di morte silenziosa: non viene ufficialmente cancellato, semplicemente smette di essere prioritario, le riunioni saltano, i budget vengono riallocati.
Un pilota invece produce risultati visibili in 6 settimane, e i risultati visibili generano energia per il passo successivo. Il quarto motivo e di apprendimento organizzativo. Il tuo team deve imparare a lavorare con l'AI, a convivere con sistemi probabilistici che a volte sbagliano, a gestire prompt e workflow automatizzati, a monitorare performance di sistemi non deterministici. Questo apprendimento non si puo fare in aula.
Si fa solo lavorando su un sistema reale, con dati reali, con utenti reali, con problemi reali. Il pilota e la scuola pratica dell'AI nella tua azienda. La strategia e solo la giustificazione a posteriori di quello che hai imparato nei piloti. Questa e l'unica sequenza corretta: prima fai 2-3 piloti su casi d'uso diversi, impari cosa funziona nel tuo contesto specifico, poi usi quell'apprendimento per costruire la strategia AI.
La strategia arriva dopo, non prima. Un'obiezione frequente e 'ma senza strategia come scelgo quale pilota fare?'. La risposta e che non hai bisogno di una strategia per scegliere il primo pilota: hai bisogno di una matrice di selezione che prende in considerazione impatto, fattibilita, disponibilita dati e sponsorship interna. Questa matrice la vediamo nella prossima sezione ed e l'unico artefatto strategico che serve prima di partire con il primo pilota.
Tutto il resto e post-razionalizzazione. Il tuo obiettivo, oggi, non e 'diventare una AI-first company'. E lanciare il primo pilota AI nelle prossime 6 settimane. Se ci riesci, nei prossimi 12 mesi ne avrai lanciati 4-6, ognuno piu ambizioso del precedente, ognuno basato sull'apprendimento del precedente. Al termine del primo anno avrai un'azienda realmente trasformata dall'AI, senza aver mai scritto un documento di strategia.
Se invece passi i prossimi 6 mesi a costruire una strategia, a fine anno avrai solo slide e fatture di consulenza. La differenza tra le due traiettorie la decide il coraggio di iniziare senza aver pianificato tutto. Le aziende italiane che oggi stanno effettivamente estraendo valore dall'AI sono quelle che hanno iniziato con piloti piccoli e scrappy nel 2023-2024, non quelle che hanno passato due anni a costruire strategie.
La differenza e ormai di due anni di vantaggio competitivo, ed e interamente imputabile alla scelta tra fare e pianificare. Scegli fare.
La matrice a 4 quadranti per scegliere il primo caso d'uso giusto
Il fallimento piu comune di un pilota AI non e tecnico: e la scelta sbagliata del primo caso d'uso. Un caso d'uso sbagliato produce un pilota tecnicamente perfetto che pero non convince nessuno, non si scala e fa perdere fiducia nell'AI come categoria. La scelta del caso d'uso e il 70% del successo del pilota. Per sceglierlo bene serve una matrice semplice a quattro quadranti, basata su due dimensioni che contano piu di ogni altra: impatto di business potenziale e fattibilita tecnica in 6 settimane.
Queste due dimensioni non sono negoziabili. Chi le ignora per seguire la cosa piu sexy o quella che fanno i competitor parte gia perdente. Dimensione 1 - Impatto di business potenziale. Si misura in una delle tre valute riconosciute in azienda: ore di lavoro risparmiate, ricavi aggiuntivi generati, errori ridotti con impatto economico quantificabile. Un caso d'uso ad alto impatto risparmia almeno 10-20 ore a settimana di lavoro qualificato, oppure genera almeno 5-10 opportunita commerciali aggiuntive al mese, oppure riduce errori che oggi costano almeno 2-5k al mese.
Se non riesci a quantificare l'impatto in una di queste tre valute, il caso d'uso ha impatto basso per definizione, anche se emotivamente sembra importante. Dimensione 2 - Fattibilita in 6 settimane. Un caso d'uso e fattibile in 6 settimane se soddisfa quattro condizioni: i dati necessari esistono gia in forma accessibile (anche se sporchi), il processo target e chiaramente definito, non dipende da fornitori terzi non coordinabili in tempi brevi, c'e almeno un utente finale disponibile a co-progettare.
Se una di queste quattro condizioni manca, il caso d'uso non e fattibile in 6 settimane: sarai lento comunque, meglio scegliere altro. Incrociando le due dimensioni ottieni quattro quadranti. Quadrante 1 - Alto impatto e alta fattibilita. E il quadrante d'oro. Qui stanno i casi d'uso che devi lanciare come primo pilota. Tipicamente sono processi ripetitivi ad alta intensita di testo: processamento di email in ingresso, classificazione di documenti, risposte a domande frequenti su base di conoscenza interna, generazione di prime bozze di documenti commerciali, estrazione di dati da fatture passive.
Sono processi noiosi, costosi in termini di tempo umano, ben definiti e con abbondanza di esempi storici su cui lavorare. Se trovi un caso d'uso in questo quadrante, non pensarci due volte: parti da li. Quadrante 2 - Alto impatto e bassa fattibilita. E il quadrante delle trappole. Qui stanno i casi d'uso affascinanti ma impossibili da portare a termine in 6 settimane: sistemi predittivi che richiedono anni di dati storici consolidati, integrazioni complesse con sistemi legacy proprietari, casi d'uso con requisiti di compliance molto rigidi come quelli sanitari o bancari, sistemi che richiedono raccolta di nuovi dati prima ancora di iniziare.
Non partire mai da questo quadrante. Mettili in backlog per il pilota 3 o 4, quando avrai gia accumulato esperienza e credibilita interna. Quadrante 3 - Basso impatto e alta fattibilita. E il quadrante dei giocattoli. Qui stanno i casi d'uso che si fanno facilmente ma che non cambiano nulla in azienda: generare post per LinkedIn automaticamente, creare riassunti di riunioni, tradurre piccole email.
Sono utili come esercizi personali, non come piloti aziendali. Il pilota deve produrre un impatto misurabile che giustifichi l'investimento nello scaling. Se il caso d'uso e in questo quadrante, l'investimento in un pilota formale non si ripaga. Fai direttamente il giocattolo con Claude o ChatGPT senza formalizzare il pilota. Quadrante 4 - Basso impatto e bassa fattibilita. E il quadrante della catastrofe.
Nessuna ragione sensata per mettere un caso d'uso qui come primo pilota. Eppure succede: spesso perche il caso d'uso e stato imposto dall'alto, o perche il consulente l'ha venduto in modo convincente, o perche lo fanno i competitor. Se ti trovi con una proposta in questo quadrante, rifiutala senza discutere. Come applicare la matrice in pratica. Fai un brainstorming di 10-15 casi d'uso potenziali con 3-5 persone chiave della tua azienda, incluso almeno un operativo del front line.
Posiziona ciascuno nella matrice dopo averlo discusso per 5-10 minuti. Scarta tutto quello che non e nel quadrante 1. Se nessun caso d'uso e nel quadrante 1, la tua azienda non ha ancora le condizioni per fare un pilota AI: investi prima in consolidamento dei dati e nella definizione di un owner interno, poi riapri la valutazione. Tra i casi d'uso del quadrante 1, scegli quello piu vicino al core business e con lo sponsor piu forte.
Un pilota su un caso d'uso periferico, anche se tecnicamente perfetto, raramente ottiene l'attenzione necessaria per scalare. Un pilota su un caso d'uso vicino al core business diventa rapidamente una priorita naturale dell'organizzazione. E se vinci quello, vinci tutto cio che viene dopo. Una regola finale di sanita: se dopo due ore di brainstorming e applicazione della matrice non hai trovato nessun caso d'uso chiaramente nel quadrante 1, non forzare la scelta.
Meglio rimandare il pilota di un mese e fare lavoro di preparazione (consolidamento dati, nomina owner, formazione base sull'AI del management) che partire con un caso d'uso tiepido. Il primo pilota e il progetto che determina se l'AI diventera un asset strutturale della tua azienda o un ricordo fallito: vale la pena aspettare 4 settimane in piu per iniziarlo giusto.
Settimane 1-2: discovery, dati, baseline misurate
Le prime due settimane del pilota sono le piu importanti e le meno attraenti. Niente di costruito, niente di visibile, solo conversazioni, analisi dati, definizioni di metriche. Molti titolari di PMI sono tentati di saltare o accelerare questa fase per partire subito con il codice. E l'errore piu comune e piu costoso di tutto il progetto. Saltare la discovery produce un prototipo che risolve il problema sbagliato, misurato con metriche inventate, validato su dati fittizi.
Il prototipo funziona in demo e fallisce il primo giorno di realta. Investire in discovery seria nelle prime due settimane e l'assicurazione contro questo fallimento. Obiettivi della settimana 1. Mappare il processo as-is, identificare chi lo esegue oggi e con quali strumenti, quantificare quanto tempo ci vuole oggi, quali sono gli errori piu frequenti, dove sta il dolore vero per chi lo esegue. Questa mappatura si fa in modo operativo: due sessioni di osservazione sul campo di chi esegue oggi il processo, una sessione di intervista strutturata con domande aperte, una sessione di shadowing per vedere come reagisce agli edge case.
Non fare questa mappatura al chiuso in una stanza con PowerPoint: vai dove il processo avviene realmente. Deliverable della settimana 1: un documento di 5-10 pagine che descrive il processo as-is passo per passo, quantifica il tempo per ciascun passo, identifica i punti di dolore e stima un primo ordine di grandezza del risparmio potenziale. Se non riesci a produrre questo documento in una settimana, il caso d'uso non e abbastanza chiaro: torna alla matrice e riconsidera.
Obiettivi della settimana 2. Consolidare i dati disponibili e misurare la baseline quantitativa. Qui si risponde a tre domande specifiche: quali dati esistono gia in formato utilizzabile, quali dati esistono ma in formato inutilizzabile che andra convertito, quali dati semplicemente non esistono e vanno raccolti ex novo. Per ciascuna delle tre categorie serve un piano concreto. La baseline quantitativa e il numero contro cui misurerai il pilota alla fine delle 6 settimane.
Deve essere misurata prima di iniziare la build, non dopo. Esempi: se il pilota e un agente per processare fatture passive, la baseline e il tempo medio attuale per processare una fattura (tipicamente 3-8 minuti) e l'accuratezza attuale (tipicamente 95-98%). Se il pilota e un chatbot customer care, la baseline e il tempo di prima risposta attuale (tipicamente 2-24 ore) e il tasso di risoluzione al primo contatto.
Se il pilota e un sistema di lead scoring, la baseline e il tasso di conversione attuale dei lead da MQL a SQL. Senza baseline misurata, il pilota non e un pilota: e un esperimento senza gruppo di controllo. Alla fine la discussione sui risultati diventa una guerra di percezioni tra chi pensa che vada bene e chi pensa che vada male, invece di un confronto tra numeri prima e dopo. La baseline si misura investendo 2-4 giorni di lavoro di una persona che conosce il processo, che raccoglie 30-100 casi reali e cronometra o misura ciascuno.
Nessun software sofisticato, solo un foglio Excel e un cronometro. Deliverable della settimana 2: un documento di baseline che riporta le metriche misurate, la metodologia di misurazione, i casi usati e le ipotesi di miglioramento attese dal pilota. Questo documento e firmato dal titolare e dall'owner interno prima di passare alla fase di build. Serve a cristallizzare le aspettative e a prevenire lo scope creep successivo.
Durante le settimane 1-2 il fornitore AI dovrebbe lavorare in parallelo su tre cose tecniche: accesso ai dati identificati nella settimana 1, preparazione dell'ambiente tecnico (account Claude o GPT, istanza n8n o Make, accesso alle API necessarie), prima scrittura dei prompt di massima per capire se l'approccio funziona qualitativamente. Questo lavoro parallelo del fornitore dura 3-5 giorni ed e il primo test della qualita dell'ingegnere assegnato al progetto: un ingegnere serio alla fine della settimana 2 ha gia fatto girare 5-10 prove qualitative su dati reali, anche se non integrate in nulla.
Se alla fine della settimana 2 il fornitore non ha nulla di toccabile, e un segnale di allarme da affrontare subito. Al termine delle settimane 1-2, l'owner interno, il titolare e il fornitore fanno una riunione di allineamento di 90 minuti che produce una decisione esplicita: si continua con questo caso d'uso, si modifica lo scope, o si ferma il pilota. Il 10-20% dei piloti dovrebbe fermarsi qui. E sano, non e un fallimento: e il sistema di matrice che ha funzionato come filtro prima di investire le settimane di build.
Una buona regola per le settimane 1-2 e la regola del no nuovi dati. Se per fare discovery ti serve raccogliere dati che oggi non esistono, il caso d'uso non e fattibile in 6 settimane. Raccogliere nuovi dati richiede settimane o mesi e non rientra nel pilota: rientra nella preparazione che deve precedere il pilota. Se scopri a meta settimana 1 che stai per raccogliere nuovi dati, fermati e torna alla matrice.
Settimane 3-4: build del primo prototipo funzionante
Le settimane 3 e 4 sono quelle in cui il prototipo prende forma. E la fase piu visibile e piu emozionante del pilota, ed e anche quella in cui il rischio di deragliamento e piu alto. I rischi non sono tecnici, sono di scope e di aspettative: il titolare vede il prototipo che inizia a funzionare e immagina subito tutte le cose che potrebbe fare, il fornitore e tentato di aggiungere feature per dimostrare bravura, gli utenti finali iniziano a chiedere modifiche che non erano previste.
Proteggere la disciplina dello scope in queste due settimane e la responsabilita dell'owner interno, ed e il momento in cui l'owner guadagna il suo ruolo nell'organizzazione. Obiettivi della settimana 3. Costruire la spina dorsale del prototipo, ovvero la versione minima che esegue il caso d'uso end to end su dati reali. Non deve essere bella, non deve gestire eccezioni, non deve avere interfaccia curata: deve solo funzionare su 5-10 casi tipici.
La build della settimana 3 in un progetto AI moderno usa tipicamente una combinazione di tre tipi di componente: un LLM come motore di ragionamento (Claude, GPT o Gemini a seconda del caso d'uso), un orchestratore di workflow come n8n, Make o Zapier per il flusso di dati tra i sistemi, e uno o due punti di integrazione con sistemi esistenti come gestionale, email, CRM o database. La combinazione di questi tre tipi di componente permette di costruire il 90% dei casi d'uso AI di PMI senza scrivere codice tradizionale, il che accelera drasticamente i tempi di build e riduce il rischio tecnico.
Alla fine della settimana 3, il prototipo deve essere in grado di ricevere un input reale (una fattura, una email, una query), processarlo con l'LLM, applicare la logica di business, produrre un output utilizzabile. Deliverable: un video di 2-3 minuti che mostra il prototipo che processa 3-5 casi reali end to end. Obiettivi della settimana 4. Allargare il prototipo a una quota rappresentativa dei casi reali, tipicamente 30-100 esempi, e iniziare a misurare l'accuratezza su un set di validazione.
Questa e la fase in cui emergono i primi problemi veri: casi che il modello non gestisce bene, edge case che erano stati sottovalutati, dati di input che hanno formati inaspettati, risposte dell'LLM che variano da una chiamata all'altra in modo imprevisto. Il lavoro della settimana 4 e sistematicamente affrontare questi problemi attraverso miglioramento dei prompt, aggiunta di esempi few-shot, introduzione di controlli di validazione, gestione delle eccezioni con fallback verso revisione umana.
Alla fine della settimana 4, il prototipo dovrebbe avere un'accuratezza misurabile su un set di almeno 30 casi reali. La soglia di accettabilita dipende dal caso d'uso: per un agente che processa fatture, l'accuratezza minima e 90-95%, ma solo se le eccezioni vengono correttamente segnalate per revisione umana. Per un chatbot customer care, la soglia e che il 70-80% delle domande riceva una risposta soddisfacente, e il resto venga correttamente escalato a un operatore umano.
Per un sistema di lead scoring, la soglia e che il top 20% dei lead scorati dal sistema abbia un tasso di conversione almeno 2x superiore alla media storica. Queste soglie vanno definite nella settimana 2 come parte dei KPI, non rinegoziate nella settimana 4 quando i risultati sono gia noti. Deliverable della settimana 4: un report di test con accuratezza misurata su set di validazione, elenco delle eccezioni gestite e non gestite, tempo medio di processamento per caso, primo confronto con la baseline misurata nella settimana 2.
Cosa non fare nelle settimane 3-4. Primo errore: iniziare a costruire interfacce utente complesse. Il prototipo non deve avere UI, o al massimo un'interfaccia minimal fatta in 2-3 ore. L'interfaccia distrae dal vero lavoro che e validare che il motore AI funzioni sul caso d'uso. L'UI la costruisci dopo, se il pilota va avanti. Secondo errore: rincorrere la perfezione dei prompt. Un prompt che funziona al 90% in 2 ore e meglio di un prompt che funziona al 95% in 2 giorni.
L'AI moderna e probabilistica e non arriverai mai al 100%: meglio lasciare il 10% di casi alla revisione umana e avere un sistema che funziona oggi, piuttosto che spendere settimane a inseguire l'ultimo 5%. Terzo errore: aggiungere feature fuori scope. Se l'owner interno o il titolare chiedono 'potresti anche fargli fare questa altra cosa?', la risposta del fornitore deve essere 'ottima idea, la aggiungiamo al backlog per il pilota 2 o per lo scaling'.
Aggiungere qualsiasi cosa dentro il pilota in corso raddoppia il rischio di non rispettare le 6 settimane. Il ritmo operativo delle settimane 3-4 deve prevedere una sync corta di 30 minuti 2-3 volte a settimana tra owner interno e fornitore, piu una demo settimanale al titolare di 15-20 minuti. Niente riunioni lunghe, niente deliverable formali: solo avanzamento misurabile e decisioni veloci sui problemi.
Alla fine della settimana 4, il titolare, l'owner interno e il fornitore fanno una riunione di valutazione di 60 minuti e decidono esplicitamente se si va avanti verso le settimane 5-6 o se si ferma qui. Fermare un pilota a fine settimana 4 e sano: hai speso circa il 70% del budget, hai imparato se il caso d'uso funziona tecnicamente, e se la risposta e no risparmi il restante 30% e tutto lo scaling successivo.
Settimane 5-6: hardening, integrazione, formazione del team
Le ultime due settimane del pilota sono quelle che trasformano un prototipo che funziona in demo in un sistema che funziona nella realta. E la fase piu sottovalutata dai fornitori e la piu decisiva per il successo del pilota. Saltare o comprimere questa fase e l'errore che separa i piloti che si scalano dai piloti che finiscono nel cassetto. Il prototipo della fine della settimana 4 gira ancora in un ambiente di test, processa casi selezionati, non ha gestione robusta degli errori, non ha logging, non ha dashboard, non ha guardrail di sicurezza, non ha un utente finale che lo usa quotidianamente.
Queste sono tutte cose che servono nelle settimane 5 e 6 per trasformarlo in qualcosa di utilizzabile. Obiettivi della settimana 5 - hardening. Il lavoro tecnico di hardening comprende sei attivita concrete: aggiunta di gestione errori e fallback per quando l'LLM non risponde o risponde in modo inaspettato, logging strutturato di ogni operazione per poter debuggare e monitorare il sistema, dashboard minima di monitoraggio per vedere quanti casi vengono processati, con che accuratezza e con quali eccezioni, guardrail di sicurezza per prevenire output inappropriati o violazioni di privacy, meccanismi di escalation verso revisione umana nei casi ambigui, documentazione operativa minima di come il sistema funziona e come intervenire in caso di problemi.
Queste attivita richiedono tipicamente 3-5 giorni di lavoro di un ingegnere serio. Saltarle o dire 'le facciamo dopo il go-live' e l'errore che fa fallire i piloti: il dopo non arriva mai, e il sistema al primo problema in produzione viene abbandonato dagli utenti. Oltre al lavoro tecnico, la settimana 5 include l'integrazione con i sistemi esistenti che sono necessari per il go-live del pilota: collegamento con il gestionale per leggere o scrivere dati, integrazione con email o CRM tipo HubSpot per ricevere input o mandare output, connessione con sistemi di autenticazione aziendale se serve controllo accessi.
L'integrazione nelle settimane 5-6 deve essere il minimo necessario per il pilota, non l'integrazione completa che servira al sistema finale. Meglio fare un'integrazione base che funziona adesso che pianificare l'integrazione perfetta che richiede altre 4 settimane. Obiettivi della settimana 6 - formazione e rollout pilota. La settimana 6 e dedicata alla parte umana del rollout. Le attivita sono quattro: sessione di formazione del gruppo pilota di utenti (tipicamente 3-10 persone) di 60-90 minuti per mostrare come usare il sistema, cosa aspettarsi, come segnalare problemi, come escalare casi ambigui.
Documentazione utente in formato breve, tipicamente 2-4 pagine di quick start con screenshot e i 5-10 scenari piu comuni. Canale di supporto tra gli utenti pilota e il team di progetto (un gruppo Telegram, Slack o WhatsApp) per raccogliere feedback in tempo reale e correggere rapidamente. Prime ore di utilizzo supervisionato in cui l'owner interno e l'ingegnere del fornitore stanno seduti accanto agli utenti mentre provano il sistema, osservano cosa va e cosa non va, aggiustano in tempo reale.
Questa ultima attivita e quella che piu fornitori saltano e che piu decide il successo. Vedere il sistema essere usato in modo reale dai veri utenti rivela in 2-3 ore cose che nessun test interno avrebbe mai scoperto. Il feedback degli utenti pilota nelle prime ore di utilizzo va poi usato per ultime correzioni veloci: un ritocco di prompt, un fix di un bug dell'integrazione, un cambio di wording nei messaggi di errore, un aggiustamento della soglia di confidenza che fa escalare un caso umano.
Queste correzioni sono piccole ma cambiano radicalmente la percezione del sistema. Uno degli errori piu comuni e non coinvolgere gli utenti finali prima della settimana 6. Il sistema viene costruito per loro ma senza di loro, e poi presentato come fatto compiuto. La resistenza al cambiamento si triplica quando gli utenti si sentono oggetti di un esperimento invece che co-progettisti. Il rimedio e anticipare: gli utenti finali devono essere coinvolti dalle sessioni di osservazione della settimana 1, dalle scelte di design della settimana 2, dalle prime demo della settimana 4.
Cosi quando arrivano alla settimana 6 non stanno usando per la prima volta il sistema: stanno rifinendo qualcosa che sentono gia loro. Questo e il segreto per ridurre la resistenza al cambiamento da barriera a sostegno. Durante le settimane 5-6 va anche fatto il confronto quantitativo con la baseline misurata nella settimana 2. I numeri del pilota si confrontano direttamente con quelli di partenza: tempo medio per caso prima e dopo, accuratezza prima e dopo, numero di eccezioni prima e dopo, costi operativi stimati prima e dopo.
Questo confronto diventa il contenuto principale del report finale del pilota e la base per la decisione della settimana 7. Un confronto fatto con rigore statistico minimo, anche su 30-50 casi, e molto piu persuasivo di qualunque narrazione soggettiva. Gli stakeholder decideranno basandosi sui numeri se i numeri sono disponibili, su impressioni se non lo sono. Deliverable di fine settimana 6: report finale del pilota di 3-5 pagine che include risultati quantitativi misurati contro la baseline, feedback qualitativo degli utenti pilota, problemi tecnici emersi e come sono stati risolti, stima onesta del costo di scaling a produzione completa, raccomandazione esplicita di scale, pivot o stop con motivazione.
Questo documento e il deliverable piu importante di tutto il pilota ed e la base della decisione che vedremo nella prossima sezione.
Settimana 7: la decisione scale / pivot / stop
Il pilota di 6 settimane non finisce con il sistema in produzione: finisce con una decisione esplicita da prendere nella settimana 7. Questa decisione e il momento piu importante di tutto il processo, ed e anche quello che la maggior parte delle PMI italiane gestisce peggio. La decisione ha tre opzioni possibili e solo tre: scale, pivot, stop. Evitare la decisione non e un'opzione, eppure e cio che succede piu spesso.
Il pilota finisce, tutti dicono 'bello interessante', il sistema resta in uno stato di limbo dove nessuno lo usa ufficialmente ma nessuno lo ferma ufficialmente, l'energia organizzativa svanisce, dopo 3 mesi il sistema e dimenticato e nessuno sa piu dirti se era scala, pivot o stop. Questa morte silenziosa brucia tutto il valore del pilota e contamina tutti i piloti futuri perche il team interno sviluppa cinismo: 'abbiamo gia fatto un pilota AI, non e successo niente'.
Evitare la morte silenziosa richiede disciplina nella settimana 7 e un meeting esplicito di decisione che produce uno dei tre esiti. Opzione 1 - Scale. La decisione di scaling si prende quando tre condizioni sono soddisfatte contemporaneamente. Prima condizione: i KPI misurati sul pilota raggiungono o superano le soglie definite nella settimana 2. Il miglioramento rispetto alla baseline deve essere misurabile, significativo e difendibile davanti al CFO o al titolare.
Seconda condizione: gli utenti pilota sono disposti a continuare a usare il sistema anche senza il supporto costante del fornitore. Questo si verifica in un modo semplice: chiedendo loro direttamente 'se domani togliessimo questo sistema, come reagiresti?'. Se la risposta e 'nessun problema, torno al metodo vecchio', il pilota e stato un esperimento carino ma non ha creato valore reale. Se la risposta e 'non se ne parla, ora ci lavoro sopra', il valore e reale.
Terza condizione: c'e chiarezza su cosa significa scaling e quanto costa. Scaling non e 'facciamo andare il sistema per piu utenti': scaling e un progetto successivo con budget definito, tempistiche definite, owner definito, KPI di fase di scaling definiti. Senza questa chiarezza, il 'si scaliamo' e un'intenzione che svanisce in due settimane. Lo scaling tipico di un pilota riuscito in PMI costa tra 20 e 80 mila euro aggiuntivi e richiede 3-5 mesi aggiuntivi.
Questi numeri vanno approvati formalmente nella settimana 7 o lo scaling non partira mai. Opzione 2 - Pivot. La decisione di pivot si prende quando i risultati del pilota rivelano che il caso d'uso originale non funziona come previsto ma emerge un caso d'uso adiacente con risultati interessanti. Questo succede piu spesso di quanto si pensi. Esempio concreto: il pilota voleva costruire un agente per gestire automaticamente le email di customer care, ma durante il pilota si e scoperto che l'85% delle email sono semplicemente richieste di stato ordine che potrebbero essere risolte da un sistema molto piu semplice che non usa AI, mentre il 15% che richiede AI sono casi complessi dove l'AI aiuta ma non sostituisce l'operatore.
Il pivot qui e costruire un sistema ibrido: automazione semplice per la maggioranza dei casi, AI come assistente per i casi complessi. Questo e un esito di successo, non di fallimento: il pilota ha prodotto l'apprendimento che evita di scalare nella direzione sbagliata. Il pivot richiede un nuovo pilota di 2-4 settimane per validare il nuovo approccio prima di investire in scaling, e va trattato come un secondo pilota con budget proprio, non come estensione del primo.
Opzione 3 - Stop. La decisione di stop si prende quando il pilota dimostra che il caso d'uso non e fattibile o non produce valore sufficiente a giustificare lo scaling. Esempi concreti: l'accuratezza del sistema non raggiunge la soglia accettabile nemmeno dopo le settimane 5-6, gli utenti pilota rifiutano attivamente di usarlo per ragioni sostanziali, il costo operativo dell'LLM in scaling risulterebbe superiore al valore generato, l'integrazione con i sistemi esistenti si e rivelata molto piu complessa del previsto.
Fermare un pilota non e un fallimento. E il risultato per cui il pilota e stato progettato: separare i casi d'uso che funzionano da quelli che non funzionano spendendo 6 settimane e 10-25k invece di 6 mesi e 100-300k. Un pilota che si ferma e un investimento che ha prodotto apprendimento, non capitale sprecato. L'unico modo per sprecare il capitale del pilota e non fermarlo quando va fermato e continuare per inerzia.
La gestione dello stop richiede cura organizzativa. Il team interno deve ricevere comunicazione esplicita che il pilota si e fermato per ragioni oggettive, non perche 'l'AI non funziona'. Il risultato deve essere documentato nel dettaglio per il prossimo pilota: cosa abbiamo imparato, quali ipotesi erano sbagliate, quali casi d'uso potrebbero funzionare meglio. Questo documento diventa asset aziendale per il prossimo tentativo.
Una nota sul timing della settimana 7. La decisione va presa entro 5-7 giorni dalla fine della settimana 6, non dopo. Oltre questo lasso, il momentum svanisce, i partecipanti chiave si distraggono con altre priorita, e la decisione diventa un non-decisione che slitta all'infinito. Blocca un meeting di 90 minuti con titolare, owner interno e fornitore entro la fine della settimana 7, con un'agenda esplicita: rivedere il report finale, discutere i risultati, prendere la decisione esplicita scale, pivot o stop, documentare la decisione e le azioni successive in un documento di 1-2 pagine firmato da tutti i presenti.
Questo e il modo professionale di chiudere un pilota AI e di iniziare il percorso successivo, qualunque esso sia. Se vuoi approfondire le tempistiche complete del sistema end to end dopo il pilota, leggi la nostra guida dedicata sui tempi di implementazione di un progetto AI in una PMI italiana. Se vuoi capire come scegliere il fornitore giusto prima ancora di lanciare il pilota, leggi l'articolo dedicato alla selezione della societa di consulenza AI per PMI.
Guide correlate
Pronto a passare dalla teoria alla pratica?
Implementiamo insieme l'AI nella tua azienda. La prima call e gratuita.