Pilota AI di 4 settimane: cosa pretendere prima di firmare

Perché tante PMI sprecano il primo pilota

Studio MIT NANDA The GenAI Divide: State of AI in Business 2025, basato su 300 deployment AI analizzati: «about 5% of AI pilot programs achieve rapid revenue acceleration; the vast majority stall». In italiano: circa il 5% dei pilot AI accelera realmente i ricavi. Il 95% si arena.

Floriano Masoero, AD Siemens Italia, sul Sole 24 Ore: «Molte aziende attivano progetti pilota di intelligenza artificiale ma poi non riescono a renderli scalabili». La diagnosi ha già un nome accettato dalla letteratura: pilotitis. Pilot che funzionano in laboratorio e non escono mai dal laboratorio.

Il pattern che vediamo ripetersi: scope creep, milestone vaghe, criteri di successo decisi a posteriori. Quando i criteri si definiscono dopo, non sono più criteri, sono giustificazioni.

Questa pagina è la lista di cose che dovreste pretendere dal vostro fornitore AI prima di firmare il pilota. Vale che siamo noi o sia chiunque altro. Se il fornitore non vi mette nero su bianco questi punti, è il segnale che non sa cosa sta facendo, o che vuole infilarvi in un progetto aperto a tempo indeterminato.

I 6 punti del pilot agreement

1. Lo scope è chiuso, non aperto

Il documento deve dire cosa è dentro e cosa è fuori. Non "automatizzeremo la reportistica produzione", ma "estrazione dati da gestionale TeamSystem + MES Acme + 4 fogli reparto, generazione report PDF settimanale con narrativa, distribuzione a 3 destinatari". Punto.

Se mancano i nomi dei sistemi, il numero dei destinatari, il formato dell'output, lo scope è aperto. Aperto significa "decideremo strada facendo" che è il peggior modo di gestire 4 settimane.

2. I criteri di successo sono numerici e firmati prima

Non "buona adozione" o "soddisfazione del team". Cose come:

Il report del lunedì arriva entro le 8:00 in 4 settimane su 4
Tasso di errore di estrazione dati < 2% sul totale documenti processati
Tempo manuale per settimana di reportistica scende sotto le 4 ore (oggi 18)

Numeri specifici, soglia minima accettabile sotto cui il pilota è fallito, metodo di misurazione concordato. Firmati dal budget holder e dallo sponsor di processo prima del kick-off. Non dopo.

3. La soglia di fallimento è esplicita

Il pilot agreement deve dire cosa succede se il pilota fallisce. Tre opzioni:

Refund completo o parziale: se i criteri di successo non sono raggiunti, parte o tutto l'investimento viene restituito. È la più favorevole per voi e la più rischiosa per il fornitore. I fornitori seri la accettano sui pilota piccoli (<5k).
No production rollout: il fornitore consegna comunque quello che ha costruito (codice, doc, learnings) ma non si va in produzione e non si firma il retainer. Voi avete pagato per provare.
Rinegoziazione scope: se i criteri non torrnano, si discute insieme se erano sbagliati i criteri o sbagliato il progetto. Pericoloso, perché tende a diventare "rinegoziazione = altri 2 mesi".

La nostra preferenza: opzione 2 con clausola "se a fine pilota i numeri non quadrano, in produzione non si va e il retainer non parte". È onesto per entrambi. Voi avete pagato il pilota, non un retainer perpetuo.

4. La timeline ha milestone settimanali, non solo finali

4 settimane senza checkpoint intermedi sono 4 settimane di rischio. Il pilot agreement deve avere milestone tipo:

Settimana 1: prototipo funzionante su un sottoinsieme ridotto. Dimostrato in call.
Settimana 2: integrazione con i vostri sistemi, test su dati veri ma in dry-run.
Settimana 3: deploy in shadow mode (il sistema gira parallelo al processo manuale, output non distribuito ufficialmente).
Settimana 4: go-live + misurazione contro criteri di successo.

Se siete a settimana 2 e non avete visto nulla di funzionante, è già un red flag. Non aspettate la settimana 4 per accorgervi.

5. La proprietà di quello che viene costruito è esplicita

Domanda: se a fine pilota decidete di non firmare il retainer, cosa rimane in mano vostra e cosa succede al sistema?

Risposta accettabile (modello servizio gestito):

I vostri dati esportabili in formati standard: CSV, Excel, JSON. Senza fattura extra, senza tergiversare.
Documentazione operativa completa: cosa fa il sistema, dove gira, quali credenziali servono per ricostruirlo da zero, mappa dei flussi.
Accesso ai log delle esecuzioni del pilota.
Periodo di grace post-disdetta: il sistema resta accessibile per 30 giorni dopo la chiusura del retainer, sufficiente per esportare dati, mostrare il flusso al successore, decidere il piano. Dopo il grace, archiviazione del sistema e conservazione dei dati esportati per altri 90 giorni in caso di richiesta tardiva.

Risposta inaccettabile:

"Avete provato il servizio, basta. Da domani spento."
"Per esportare i vostri dati c'è una fattura aggiuntiva"
"I dati sono nostri, non vostri"

Pretendete che il pilot agreement specifichi data ownership (vostri sempre) e periodo di transizione minimo. Il codice della piattaforma può legittimamente restare al fornitore (è il suo IP, è normale nel modello servizio gestito). I vostri dati no, mai.

6. I costi extra sono tetti, non porte aperte

Il prezzo del pilota deve essere fisso. Punto. Le voci che capitano fuori budget vanno definite a priori:

API cost dei modelli AI durante il pilota: di solito incluso o capped (es. "fino a 100€ di consumi modello, sopra fatturati a costo")
Eventuali licenze software che dovete attivare voi (es. account Apollo, eventuali SaaS terzi indispensabili al flusso)
Tempo dei vostri controller / IT per le sessioni di calibrazione: che è tempo vostro, ma va dimensionato

Niente "ti faccio sapere a fine progetto quanto costano gli extra". Questo è il modo più antico al mondo per far esplodere un budget.

Le 3 domande che vi diranno se il fornitore è serio

Prima di firmare, fate queste 3 domande in chiamata. Le risposte vi diranno tutto.

1. "Quante volte avete fatto questo pilota in formato 4 settimane?"
Se la risposta è "è la prima volta su un pilota strutturato così", state attenti. Se è "abbiamo fatto X pilota di questo tipo, due hanno fallito perché [motivo concreto]", è un buon segnale. Un fornitore che vi dice di non aver mai sbagliato sta mentendo o ha fatto pochissimo.

2. "Cosa succede se al kick-off scopriamo che i dati di partenza sono peggio di quanto pensavate?"
Risposta giusta: "Lo diciamo subito, e decidiamo se rifare lo scope o uscire dal pilota con quello che è stato fatto fino a lì". Risposta sbagliata: "Va beh, ci adattiamo".

3. "Se nel pilota lavorate con uno dei nostri controller, possiamo intervistarlo a metà progetto senza il fornitore in chiamata?"
Risposta giusta: "Certo, anzi vi consigliamo di farlo". Risposta sbagliata: "Preferiremmo essere presenti per coordinare".

Quando un pilota di 4 settimane non è la cosa giusta

Onestamente: il pilota fisso a 4 settimane non funziona per tutto. Tipicamente non funziona quando:

Il processo da automatizzare ha più di 5 sistemi diversi a monte (in genere serve fase 1 di mappatura più lunga)
I dati di partenza sono notoriamente sporchi (es. anagrafiche fornitori non normalizzate da 10 anni). In quel caso il pilota dura 6-8 settimane, e va detto subito.
Il vostro team interno non ha tempo da dedicare nelle prossime 4 settimane (es. fine anno fiscale, lancio prodotto). Posticipate, non sprecate il budget.

Un fornitore serio vi dice "su questo caso non parto in 4 settimane, parto in 8" o "rifate la chiamata fra 6 settimane quando avete il bilancio chiuso". Quello che vi dice "parto la prossima settimana" senza fare queste domande è quello da cui state alla larga.

Il nostro pilot agreement standard

Quando partiamo con un cliente, il pilot agreement che firmiamo contiene tutti i 6 punti sopra. Lo condividiamo in bozza prima della firma, lo discutiamo con il vostro legal se serve, e lo customizziamo sul vostro caso. Costa zero ricevere la bozza e leggerla.