DECISION TOOLKIT · GATE DI DELIVERY
Fare in modo che ogni transizione meriti la successiva
Le nove fasi non sono una checklist. Sono obblighi di evidenza: ogni transizione riduce un’incertezza diversa e protegge l’investimento seguente.
Senza evidenza non c’è transizione. Riaprire un gate precedente è apprendimento, non fallimento.
La maggior parte delle autopsie dei progetti AI accusa il colpevole sbagliato. Il rapporto finale condanna il modello: non abbastanza preciso, non abbastanza affidabile, «non pronto per il nostro business». Nei nostri mandati osserviamo quasi sempre altro. Il modello funzionava. Ciò che mancava era un’intera fase del progetto: nessuno aveva misurato il workflow prima di cambiarlo, nessuno aveva definito cosa avrebbe giustificato uno stop, nessuno aveva costruito un ambiente di valutazione prima di esporre il sistema a utenti reali.
Quando un progetto AI fallisce, cercate la fase saltata prima di cercare il modello difettoso. Troverete quasi sempre prima la fase.
Il problema non è una mancanza generale di metodo — le organizzazioni sanno consegnare progetti. È che l’AI sposta il rischio in luoghi inconsueti: la qualità è probabilistica, la prova richiede una baseline, i permessi diventano una questione di architettura e il valore non sopravvive senza governance. Da qui questo framework, distillato dai nostri mandati: l’anatomia completa di un progetto AI enterprise, in nove fasi.
Il framework in sintesi
Un progetto AI end-to-end attraversa nove fasi. Tre riguardano il decidere: intento, diagnosi, portafoglio. Tre riguardano il costruire: architettura, fondamenta, pilota. Tre riguardano il valore: evidenza, industrializzazione, valore in continuo. Ogni fase produce deliverable identificabili, espone una trappola ricorrente e termina con un criterio di uscita verificabile. Finché quel criterio non è soddisfatto, avanzare non elimina il lavoro: lo sposta più a valle, dove costa di più.
La sequenza non vieta l’iterazione — un pilota può rimandare all’architettura, un’evidenza può riaprire il portafoglio. Ma le decisioni sono ordinate: non si sceglie un pattern tecnico prima di aver scelto un problema, e non si estende un sistema prima di averne contato gli errori.
Il framework vale per un assistente documentale come per un agente che tocca i sistemi di produzione: cambia solo il peso relativo delle fasi. Un caso a basso rischio attraversa le nove fasi in poche settimane con deliverable leggeri; un caso che influenza decisioni sui clienti passa più tempo in architettura, fondamenta e pilota. Saltare una fase non è mai un risparmio di tempo: è un trasferimento di debito verso la produzione.
Fase 1 — La decisione d’intento
Ogni progetto inizia con un’intenzione; pochi iniziano con una decisione. La fase 1 trasforma «ci serve l’AI» in una scelta esplicita: quale problema, portato da quale sponsor, con quale criterio di abbandono. Quest’ultimo punto è il deliverable più importante — e il più raramente prodotto. Decidere prima dell’investimento cosa giustificherebbe uno stop costa un’ora di lucidità; deciderlo dopo costa una negoziazione politica.
Deliverable. Una nota d’intento di una pagina: il problema formulato come risultato di workflow da cambiare, uno sponsor nominato con tempo realmente riservato, il budget della fase di prova e il criterio di abbandono per iscritto.
La trappola classica. Il progetto specchio: lanciato perché un concorrente ha annunciato qualcosa, senza un problema proprio. Lo sponsor è un nome su una slide, non una persona che deciderà quando servirà una scelta difficile.
Criterio di uscita. Potete passare alla fase successiva quando lo sponsor enuncia senza appunti il risultato da cambiare e le condizioni di stop — ed entrambi figurano in un documento che ha firmato.
Fase 2 — Diagnosi e baseline
Non si può migliorare un workflow che non si è misurato; lo si può solo cambiare. La fase 2 documenta il workflow reale, non il processo ufficiale: chi fa cosa, dove si perde tempo, dove si concentrano le rilavorazioni, quali dati circolano e sotto quali vincoli legali. È anche il momento di congelare la baseline che renderà possibile qualsiasi prova successiva.
Deliverable. Una mappa del workflow come viene realmente praticato; baseline quantificate — tempo di ciclo, tasso di rilavorazione, tasso di eccezioni, costo unitario, variabilità qualitativa; un inventario dei dati e dei sistemi coinvolti, con i rispettivi owner.
La trappola classica. Misurare a posteriori. Senza baseline, il team dovrà provare il valore del pilota contro i ricordi — e i ricordi perdono sempre contro un CFO scettico. Variante frequente: documentare il processo teorico del manuale qualità, che nessuno segue.
Criterio di uscita. Potete avanzare quando sapete, numeri alla mano, quanto costa oggi il workflow — e la persona che lo fa funzionare riconosce quei numeri come propri.
Fase 3 — Portafoglio e primo caso
Anche quando il mandato riguarda un solo caso d’uso, va scelto contro alternative. La fase 3 costruisce un portafoglio di candidati e li valuta su due assi: il potenziale — rilevanza economica, impatto sugli utenti, importanza strategica — e l’eseguibilità — accesso ai dati, complessità d’integrazione, controlli richiesti, possibilità di valutazione. Il primo caso non è quello che promette di più: è quello che combina un valore significativo con il percorso più breve verso evidenze affidabili.
Deliverable. Un portafoglio valutato su potenziale × eseguibilità; un primo caso scelto e documentato; l’elenco dei casi rinviati con la ragione del rinvio — eviterà di rigiocare lo stesso dibattito ogni trimestre.
La trappola classica. Scegliere il caso più spettacolare: spesso rivolto ai clienti, spesso ad alto rischio, quasi sempre il più lento da provare. Un primo fallimento visibile costa più credibilità di quanta ne portino tre successi silenziosi.
Criterio di uscita. Potete avanzare quando sponsor, owner del workflow e team tecnico difendono lo stesso primo caso — per le stesse ragioni.
Fase 4 — Architettura e confini
Prima di costruire vanno tracciati i confini: quali dati entrano, quali permessi si applicano, quale pattern tecnico regge il caso e cosa resta reversibile. Sulla scelta del pattern, la nostra regola coincide con le linee guida di ingegneria pubblicate da Anthropic sulla costruzione di agenti: partire dal pattern più semplice che basta — una chiamata con strumenti, una catena di prompt, un router — e andare verso l’agentico solo quando il caso lo richiede in modo dimostrabile. Sull’integrazione, standard aperti come il Model Context Protocol riducono il vincolo verso i fornitori e preparano la reversibilità.
Deliverable. Un diagramma dei flussi di dati con gli owner; un modello di permessi in cui il sistema eredita i diritti dell’utente — mai di più; una scelta di pattern giustificata per iscritto; un’analisi di reversibilità: quanto costerebbe cambiare modello o fornitore.
La trappola classica. La sovra-architettura: costruire un agente autonomo dove sarebbe bastata una catena di prompt, e poi passare mesi a fare debugging di un’autonomia di cui nessuno aveva bisogno. Esiste anche la trappola inversa: ignorare i permessi e scoprire durante il pilota che l’assistente mostra documenti che l’utente non avrebbe mai dovuto vedere.
Criterio di uscita. Potete avanzare quando ogni dato che entra ed esce dal sistema ha un percorso documentato, un owner e un confine di permessi verificabile.
Fase 5 — Le fondamenta
La fase 5 costruisce ciò che una demo non mostra mai: identità e accessi provisionati in modo pulito, connettori dati affidabili, controlli operativi e, soprattutto, l’ambiente di valutazione. È lui a distinguere un progetto governabile da un volo alla cieca: un set di casi reali, rappresentativi e volutamente scomodi, rieseguibile dopo ogni modifica. Il NIST AI Risk Management Framework dice la stessa cosa nel proprio vocabolario: si governa solo ciò che si sa mappare e misurare.
Deliverable. Account di servizio con perimetro minimo; accessi ai dati operativi e registrati nei log; un set di valutazione costruito su casi reali, inclusi i casi limite; i controlli di base — logging, soglie di allerta, procedura d’incidente.
La trappola classica. Saltare l’ambiente di valutazione per «arrivare prima al pilota». Il team poi regola i prompt a sensazione, incapace di distinguere un miglioramento da una regressione, e il pilota diventa una sequenza di impressioni contraddittorie.
Criterio di uscita. Potete avanzare quando potete rieseguire il vostro set di valutazione e ottenere un punteggio riproducibile — prima che un solo utente reale abbia toccato il sistema.
Fase 6 — Il pilota supervisionato
Il pilota non testa la tecnologia: testa il workflow modificato, i suoi controlli e i suoi umani. La fase 6 espone il sistema a un perimetro ristretto e nominato, con validazione umana sistematica all’inizio, poi a campione man mano che la fiducia si costruisce sui fatti. Ogni errore viene tipizzato: gravità, causa, rilevabilità. È questa contabilità degli errori — non l’entusiasmo dei primi utenti — ad alimentare la decisione della fase 7. La supervisione non è sfiducia verso il sistema: è lo strumento che permetterà, evidenze alla mano, di ridurla progressivamente.
Deliverable. Un perimetro scritto: utenti nominati, casi coperti, casi esplicitamente esclusi; un circuito di validazione umana con regole di campionamento; un registro di errori tipizzati; soglie di qualità fissate prima del lancio, non dopo.
La trappola classica. Il pilota-demo: tre utenti entusiasti, nessun registro degli errori e una decisione di estensione basata su aneddoti. Gli errori che non si contano durante il pilota si contano più tardi come incidenti.
Criterio di uscita. Potete avanzare quando disponete di un tasso di errore misurato per tipo di caso, confrontato con la baseline umana della fase 2 — non di una sensazione generale.
Fase 7 — Evidenza e decisione di estensione
La fase 7 è una sala decisionale, non una celebrazione. Tre esiti sono legittimi: scale — le soglie sono raggiunte, si estende; adapt — il valore esiste ma altrove o in altro modo, si riconfigura; stop — le evidenze mancano, ci si ferma e si capitalizzano gli apprendimenti. Uno stop deciso sulle evidenze è un successo di governance; un’estensione per inerzia è un fallimento differito. Gli ordini di grandezza restano forchette — un tempo di elaborazione ridotto dal 30 al 50 per cento sui casi standard, ad esempio — ed è la vostra baseline della fase 2 a trasformare una forchetta in un fatto.
Deliverable. Un dossier di evidenze: delta rispetto alla baseline, costi completi — costruzione, esercizio, supervisione —, incidenti e loro risoluzione, adozione reale; una decisione scritta — scale, adapt o stop — firmata dallo sponsor.
La trappola classica. L’estensione per inerzia: «il pilota è andato bene», quindi si estende, senza confrontare i risultati con le soglie — spesso perché nessuna soglia era stata fissata nella fase 6. Lo stop non è mai stato un’opzione reale, solo una riga su una slide.
Criterio di uscita. Potete avanzare quando la decisione è presa sui numeri, firmata, e l’opzione stop era davvero sul tavolo.
Fase 8 — Industrializzazione
Andare in produzione non è la fine del progetto: è l’inizio delle operazioni. La fase 8 trasforma un pilota che funziona in un servizio che regge: osservabilità — trace, costo per richiesta, deriva della qualità —, un modello operativo chiaro — chi risponde quando qualcosa si rompe, con quali impegni —, gestione dei costi e formazione dei team sul nuovo workflow, non solo sullo strumento. Qui si decide anche la sostenibilità economica del sistema: un costo per richiesta accettato in pilota può diventare indifendibile su scala se nessuno lo sorveglia.
Deliverable. Dashboard di osservabilità in produzione; un runbook operativo con un owner nominato; budget e allerte sui costi; un piano di formazione ancorato al workflow; la security review prima del passaggio in produzione.
La trappola classica. Il passaggio di consegne fantasma: il team di progetto passa al tema successivo, nessuno è reperibile, i costi derivano in silenzio e la qualità si degrada senza testimoni. Il sistema muore in produzione — lentamente, e senza certificato di morte.
Criterio di uscita. Potete avanzare quando il sistema ha un owner operativo nominato, un budget monitorato e una qualità misurata in continuo — non solo nei giorni d’incidente.
Fase 9 — Valore in continuo
L’ultima fase non ha fine: è il regime permanente. Le baseline tornano vive — rimisurate a intervalli regolari, perché workflow, volumi e modelli cambiano. Una breve governance mensile esamina valore, costi, rischi e trade-off. E i guadagni dimostrati finanziano i casi successivi del portafoglio: è il reinvestimento, non l’entusiasmo, a trasformare un primo progetto in un programma.
Deliverable. Baseline rimisurate e datate; una review mensile con agenda fissa — valore, costi, incidenti, rischi, decisioni; una logica di reinvestimento che collega i guadagni provati ai prossimi casi del portafoglio.
La trappola classica. Dichiarare vittoria al go-live e smettere di misurare. Sei mesi dopo, nessuno sa se il sistema crea ancora valore — né se ne abbia mai creato. Il budget successivo si negozia allora sulla fiducia, davanti a un CFO che non ne ha.
Criterio di uscita. Questa fase non si abbandona; si mantiene. Siete al ritmo giusto quando ogni review mensile produce almeno una decisione: estendere, adattare, fermare o reinvestire.
I nove criteri di uscita in una tabella
| Fase | Potete avanzare quando… |
|---|---|
| 1. Decisione d’intento | Lo sponsor enuncia senza appunti il risultato da cambiare e il criterio di abbandono. |
| 2. Diagnosi & baseline | Il costo attuale del workflow è quantificato e validato dal suo owner. |
| 3. Portafoglio & primo caso | Sponsor, business e tecnica difendono lo stesso caso, per le stesse ragioni. |
| 4. Architettura & confini | Ogni dato ha un percorso documentato, un owner, un permesso verificabile. |
| 5. Fondamenta | Il set di valutazione produce un punteggio riproducibile prima di ogni utente reale. |
| 6. Pilota supervisionato | Il tasso di errore è misurato per tipo di caso e confrontato con la baseline umana. |
| 7. Evidenza & estensione | La decisione scale, adapt o stop è presa sui numeri e firmata. |
| 8. Industrializzazione | Owner operativo nominato, budget monitorato, qualità misurata in continuo. |
| 9. Valore in continuo | Ogni review mensile produce almeno una decisione. |
Dal framework al piano di esecuzione
Nove fasi stanno in un articolo; la loro esecuzione sta in un piano. Per mostrare concretamente cosa produce ogni fase, abbiamo anonimizzato un piano di implementazione completo di circa cinquanta pagine, tratto da un mandato reale: percorre le nove fasi deliverable per deliverable, dalla nota d’intento della fase 1 alle review mensili della fase 9, con i modelli di documento e le soglie utilizzati.
Due regole riassumono l’uso del framework. Non saltate nessuna fase: ognuna esiste perché la sua assenza ha un costo documentato. E non trasformatelo in burocrazia: su un caso semplice, una fase può stare in una riunione e due pagine. Ciò che conta non è la durata di una fase, ma che il suo criterio di uscita sia soddisfatto.
Da dove iniziare lunedì
- Nominate lo sponsor e fategli scrivere il criterio di abbandono — prima di qualsiasi conversazione sugli strumenti.
- Scegliete un workflow e misuratelo per una o due settimane: tempo di ciclo, rilavorazioni, eccezioni, costo unitario.
- Valutate da tre a cinque casi candidati su potenziale × eseguibilità, e tenetene uno solo.
- Disegnate su una pagina i flussi di dati e il modello di permessi del caso scelto.
- Costruite un set di valutazione a partire da casi reali — inclusi quelli scomodi — prima di scrivere un solo prompt.
- Fissate per iscritto le soglie di qualità del pilota e la data della decisione scale, adapt o stop.
- Prenotate fin d’ora la review mensile nelle agende: una governance non pianificata non esiste.
La differenza tra un progetto AI che prova e un progetto AI che promette si gioca raramente nella scelta del modello. Si gioca nella disciplina delle nove fasi — e si vede fin dalla prima settimana.