Anatomia di un progetto IA dall’inizio alla fine: le nove fasi

AIUTO ALLA DECISIONE · PUNTI DI DECISIONE

Ogni passo deve meritare il successivo

Le nove fasi non sono una lista di controllo. Ognuna elimina un’incertezza diversa e protegge l’investimento successivo.

01L’incertezza eliminata in ogni fase

01Intenzioneobiettivo vago

02Misura di partenzanulla di misurato

03Portafoglioprimo caso sbagliato

04Architetturaconfini poco chiari

05Fondamentaimpossibile da testare

06Progetto pilotaprocesso non collaudato

07Provacausa incerta

08Produzioneesercizio fragile

09Valoreportafoglio alla deriva

Senza prova non c’è passo successivo. Tornare a una fase precedente è apprendimento, non fallimento.

La maggior parte dei bilanci dei progetti IA sbaglia colpevole. Il rapporto finale accusa il modello: non abbastanza preciso, non abbastanza affidabile, «non pronto per il nostro mestiere». Nei nostri incarichi constatiamo quasi sempre altro. Il modello funzionava. Mancava un’intera fase del progetto: nessuno aveva misurato il processo prima di modificarlo, nessuno aveva definito che cosa avrebbe giustificato un arresto, nessuno aveva costruito un ambiente di prova prima di esporre il sistema a utenti veri.

Quando un progetto IA fallisce, cercate la fase saltata prima di cercare il modello colpevole. Troverete quasi sempre prima la fase.

Il problema non è la mancanza di metodo in generale: le organizzazioni sanno condurre progetti. È che l’IA sposta il rischio in punti insoliti. La qualità è probabilistica, la prova richiede una misura iniziale, i diritti di accesso diventano una questione di architettura e il valore non regge senza un seguito. Da qui questo metodo, ricavato dai nostri incarichi: l’anatomia completa di un progetto IA aziendale, in nove fasi.

Il metodo in sintesi

Un progetto IA dall’inizio alla fine attraversa nove fasi. Tre riguardano la decisione: l’intenzione, la diagnosi, il portafoglio. Tre riguardano la costruzione: l’architettura, le fondamenta, il progetto pilota. Tre riguardano il valore: la prova, la messa in produzione, il valore nel tempo. Ogni fase produce risultati riconoscibili, espone una trappola ricorrente e si chiude con un criterio di uscita verificabile. Finché quel criterio non è soddisfatto, passare oltre non elimina il lavoro: lo rimanda dove costa di più.

L’ordine non vieta i ritorni indietro: un progetto pilota può rimandare all’architettura, una prova può riaprire il portafoglio. Le decisioni, però, seguono un ordine: non si sceglie una soluzione tecnica prima di aver scelto un problema, e non si estende un sistema prima di averne contato gli errori.

Il metodo vale per un assistente documentale come per un agente che agisce in produzione; cambia solo il peso delle fasi. Un caso a basso rischio attraversa le nove fasi in qualche settimana, con risultati leggeri; un caso che influenza decisioni verso i clienti passa più tempo su architettura, fondamenta e progetto pilota. Saltare una fase non fa mai guadagnare tempo: trasferisce un debito verso la produzione.

DECIDERE

1. Intenzione
2. Misura di partenza
3. Portafoglio

COSTRUIRE

4. Architettura
5. Fondamenta
6. Progetto pilota

PROVARE ED ESTENDERE

7. Prova
8. Produzione
9. Valore

Ogni fase ha un criterio di uscita.

Fase 1: la decisione d’intenzione

Ogni progetto comincia con un’intenzione; pochi cominciano con una decisione. La fase 1 trasforma «ci serve l’IA» in una scelta esplicita: quale problema, sostenuto da quale committente, con quale criterio di abbandono. Quest’ultimo punto è il risultato più importante, e quello prodotto più di rado. Decidere prima di investire che cosa giustificherebbe un arresto costa un’ora di lucidità; deciderlo dopo costa una trattativa politica.

Risultati. Una nota d’intenzione di una pagina: il problema formulato come un risultato di processo da cambiare, un committente designato che riserva davvero del tempo, il budget della fase di prova e il criterio di abbandono messo per iscritto.

La trappola classica. Il progetto per imitazione: si parte perché un concorrente ha fatto un annuncio, senza un problema proprio. Il committente è un nome su una presentazione, non una persona che deciderà al momento giusto.

Criterio di uscita. Il committente enuncia senza appunti il risultato da cambiare e le condizioni di arresto, ed entrambi figurano in un documento che ha firmato.

Fase 2: la diagnosi e la misura iniziale

Non si può migliorare un processo che non si è misurato; lo si può solo cambiare. La fase 2 descrive il lavoro reale, non il processo ufficiale: chi fa che cosa, dove si perde tempo, dove si concentra il lavoro rifatto, quali dati circolano e con quali vincoli legali. È anche il momento di fissare la misura iniziale che renderà possibile ogni prova.

Risultati. Una descrizione del processo così come viene praticato; misure in cifre (tempi, tasso di lavoro rifatto, tasso di eccezioni, costo per pratica, scarti di qualità); un inventario dei dati e dei programmi interessati, con i loro responsabili.

La trappola classica. Misurare a posteriori. Senza misura iniziale, il team dovrà dimostrare il valore del progetto pilota contro dei ricordi, e i ricordi perdono sempre contro lo scetticismo del direttore finanziario. Variante frequente: descrivere il processo del manuale qualità, che nessuno segue.

Criterio di uscita. Sapete quanto costa oggi il processo, cifre alla mano, e la persona che lo fa funzionare riconosce quelle cifre come proprie.

Fase 3: il portafoglio e il primo caso

Anche quando l’incarico riguarda un solo caso d’uso, bisogna sceglierlo rispetto ad altri. La fase 3 riunisce più candidati e li valuta su tre criteri: il guadagno (portata economica, effetto per gli utenti, importanza strategica), lo sforzo (accesso ai dati, complessità dei collegamenti, controlli necessari, possibilità di fare prove) e il rischio (dati in gioco, conseguenze di un errore). Il primo caso non è quello che promette di più, ma quello che combina un guadagno significativo e la strada più breve verso una prova affidabile.

Risultati. Un portafoglio valutato per guadagno, sforzo e rischio; un primo caso scelto e documentato; l’elenco dei casi scartati, con il motivo del rinvio, che eviterà di riaprire 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 dimostrare. Un primo insuccesso visibile costa più credibilità di quanta ne portino tre successi discreti.

Criterio di uscita. Il committente, il responsabile del processo e il team tecnico difendono lo stesso primo caso, per le stesse ragioni.

Fase 4: l’architettura e i confini

Prima di costruire bisogna tracciare i confini: quali dati entrano, quali diritti si applicano, quale soluzione tecnica sostiene il caso e che cosa resta reversibile. Sulla scelta della soluzione, la nostra regola coincide con i lavori pubblicati da Anthropic sulla costruzione di agenti: cominciare dalla soluzione più semplice che basta (una chiamata a uno strumento, una serie di istruzioni, uno smistamento) e passare a un agente autonomo solo se il caso lo richiede in modo dimostrato. Sul fronte dell’integrazione, standard aperti come il Model Context Protocol riducono la dipendenza dai fornitori e preparano la reversibilità.

Risultati. Uno schema dei flussi di dati con i loro responsabili; un modello di diritti in cui il sistema eredita i diritti dell’utente, mai di più; una scelta di soluzione motivata per iscritto; un’analisi di reversibilità: quanto costerebbe un cambio di modello o di fornitore.

La trappola classica. Fare troppo: costruire un agente autonomo dove bastava una serie di istruzioni, poi passare mesi a correggere un’autonomia di cui nessuno aveva bisogno. Esiste anche la trappola opposta: ignorare i diritti di accesso e scoprire durante il progetto pilota che l’assistente mostra documenti che l’utente non avrebbe mai dovuto vedere.

Criterio di uscita. Ogni dato che entra nel sistema o ne esce ha un percorso documentato, un responsabile e un confine di accesso verificabile.

Fase 5: le fondamenta

La fase 5 costruisce ciò che non si vede in una dimostrazione: identità e accessi attribuiti correttamente, collegamenti ai dati affidabili, controlli di esercizio e, soprattutto, l’ambiente di prova. È questo a distinguere un progetto guidato da un progetto alla cieca: una serie di casi reali, rappresentativi e volutamente difficili, che si può ripetere a ogni modifica. Il quadro di gestione dei rischi dell’IA del NIST dice la stessa cosa a modo suo: si governa solo ciò che si sa descrivere e misurare.

Risultati. Account tecnici con diritti minimi; accessi ai dati operativi e registrati; una serie di prove costruita su casi reali, compresi i casi limite; i controlli di base (registrazione delle attività, soglie di allerta, procedura in caso di incidente).

La trappola classica. Saltare l’ambiente di prova per «arrivare prima al progetto pilota». Il team modifica poi le istruzioni a occhio, senza poter distinguere un miglioramento da un peggioramento, e il progetto pilota diventa una serie di impressioni contraddittorie.

Criterio di uscita. Potete ripetere la vostra serie di prove e ottenere un risultato riproducibile prima che un solo utente reale abbia toccato il sistema.

Fase 6: il progetto pilota supervisionato

Il progetto pilota non mette alla prova la tecnologia: mette alla prova il processo modificato, i suoi controlli e le persone che lo svolgono. La fase 6 apre il sistema a un ambito ristretto e definito per nome, con una convalida umana sistematica all’inizio, poi a campione man mano che la fiducia si costruisce sui fatti. Ogni errore viene classificato: gravità, causa, facilità di individuazione. È questo conteggio degli errori, e non l’entusiasmo dei primi utenti, ad alimentare la decisione della fase 7. La supervisione non è sfiducia verso il sistema: è lo strumento che permetterà di alleggerirla, prove alla mano.

Risultati. Un ambito scritto (utenti designati, casi coperti, casi esplicitamente esclusi); un circuito di convalida umana con le sue regole di campionamento; un registro degli errori classificati; soglie di qualità fissate prima del lancio, non dopo.

La trappola classica. Il progetto pilota vetrina: tre utenti entusiasti, nessun registro degli errori e una decisione di estensione fondata su aneddoti. Gli errori che non si contano durante il progetto pilota si contano più tardi come incidenti.

Criterio di uscita. Disponete di un tasso di errore misurato per tipo di caso e confrontato con la misura iniziale della fase 2, non di una sensazione generale.

Fase 7: la prova e la decisione di estensione

La fase 7 è una riunione di decisione, non una celebrazione. Tre esiti sono legittimi: estendere, perché le soglie sono raggiunte; adattare, perché il valore esiste ma altrove o in altro modo; fermare, perché le prove mancano, conservando ciò che si è imparato. Un arresto deciso sulla base delle prove è un successo di gestione; un’estensione per inerzia è un insuccesso rinviato. Il guadagno si quantifica con lo scarto tra i risultati del progetto pilota e la misura iniziale della fase 2: è questa a trasformare una stima in un fatto.

Risultati. Un dossier di prova: scarto rispetto alla misura iniziale, costi completi (costruzione, esercizio, supervisione), incidenti e loro soluzione, utilizzo reale; una decisione scritta (estendere, adattare o fermare) firmata dal committente.

La trappola classica. L’estensione per inerzia: «il progetto pilota è andato bene», quindi si estende, senza confrontare i risultati con le soglie, spesso perché nella fase 6 non era stata fissata alcuna soglia. L’arresto non è mai stato un’opzione reale, solo una riga su una presentazione.

Criterio di uscita. La decisione è presa sulla base delle cifre, firmata, e l’arresto era davvero sul tavolo.

Fase 8: la messa in produzione

Mettere in produzione non è la fine del progetto: è l’inizio dell’esercizio. La fase 8 trasforma un progetto pilota che funziona in un servizio che regge: monitoraggio (tracce, costo per richiesta, calo di qualità), organizzazione dell’esercizio (chi risponde quando qualcosa si rompe, con quali impegni), controllo dei costi e formazione dei team al nuovo processo, non solo allo strumento. È qui che si gioca la sostenibilità economica: un costo per richiesta accettato durante il progetto pilota può diventare indifendibile a pieno volume se nessuno lo sorveglia.

Risultati. Quadri di monitoraggio in produzione; una procedura di esercizio con un responsabile designato; budget e allerte sui costi; un piano di formazione ancorato al processo; la revisione di sicurezza prima della messa in produzione.

La trappola classica. Il passaggio di consegne fantasma: il team di progetto passa all’argomento successivo, nessuno è di picchetto, i costi derivano in silenzio e la qualità si degrada senza testimoni. Il sistema muore in produzione, lentamente, senza che nessuno se ne accorga.

Criterio di uscita. Il sistema ha un responsabile dell’esercizio designato, un budget seguito e una qualità misurata in continuo, non solo nei giorni di incidente.

Fase 9: il valore nel tempo

L’ultima fase non ha una fine: è il regime permanente. Le misure vengono ripetute a intervalli regolari, perché il processo, i volumi e i modelli cambiano. Una breve revisione mensile esamina valore, costi, rischi e scelte da fare. E i guadagni dimostrati finanziano i casi successivi del portafoglio: è il reinvestimento, non l’entusiasmo, a trasformare un primo progetto in un programma.

Risultati. Misure ripetute e datate; una revisione mensile con un ordine del giorno fisso (valore, costi, incidenti, rischi, decisioni); una regola di reinvestimento che collega i guadagni dimostrati ai casi successivi.

La trappola classica. Dichiarare vittoria alla messa in produzione 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 direttore finanziario che non ne ha.

Criterio di uscita. Questa fase non si lascia, si mantiene. Siete al regime giusto quando ogni revisione mensile produce almeno una decisione: estendere, adattare, fermare o reinvestire.

I nove criteri di uscita in una tabella

Dal metodo al piano di attuazione

Nove fasi stanno in un articolo; la loro attuazione sta in un piano. Per mostrare concretamente che cosa produce ogni fase, abbiamo reso anonimo un piano di implementazione completo di una sessantina di pagine, tratto da un incarico reale: sviluppa le nove fasi risultato per risultato, dalla nota d’intenzione alle revisioni mensili, con i modelli di documenti e le soglie utilizzate.

Due regole riassumono l’uso del metodo. Non saltate nessuna fase: ognuna esiste perché la sua assenza ha un costo. 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 cominciare lunedì

1. Designate il committente e fategli mettere per iscritto il criterio di abbandono, prima di qualsiasi conversazione sugli strumenti.
2. Scegliete un processo e misuratelo per una o due settimane: tempi, lavoro rifatto, eccezioni, costo per pratica.
3. Valutate da tre a cinque casi candidati per guadagno, sforzo e rischio, e tenetene uno solo.
4. Disegnate su una pagina i flussi di dati e i diritti di accesso del caso scelto.
5. Costituite una serie di prove a partire da casi reali, compresi quelli difficili, prima di scrivere la minima istruzione.
6. Fissate per iscritto le soglie di qualità del progetto pilota e la data della decisione di estendere, adattare o fermare.
7. Riservate fin da ora la revisione mensile nelle agende: un seguito che non è pianificato non esiste.

La differenza tra un progetto IA che dimostra e un progetto IA che promette si gioca raramente nella scelta del modello. Si gioca nella disciplina delle nove fasi, e si vede fin dalla prima settimana.

Come possiamo aiutarvi

Le fasi da 1 a 3 si preparano con le vostre direzioni nell’ambito dell’Accompagnamento IA. Le fasi da 4 a 9, dall’architettura alla messa in produzione e al seguito, rientrano nell’offerta Engineering IA: analisi preliminare da una a tre settimane, poi preventivo vincolante, oppure abbonamento se più progetti si susseguono. Per una PMI, la versione breve di questo metodo è il progetto pilota di 30 giorni.