Come governare un progetto di implementazione dell’intelligenza artificiale

Il problema è la responsabilità, non la tecnologia

Raramente le organizzazioni faticano a individuare un caso d’uso. Faticano a portarlo dalla dimostrazione all’operatività quotidiana. Il pilota viene approvato, il fornitore ingaggiato, un promotore interno produce un risultato convincente, e poi l’iniziativa si arena nello spazio tra la prova di concetto e il processo aziendale che avrebbe dovuto cambiare.

In molti casi il problema di fondo è strutturale. Il pilota ha uno sponsor ma non un responsabile dell’esecuzione. Ha un budget ma non una baseline. Tocca dati di una funzione, un processo di un’altra e un profilo di rischio di una terza, e nessuno risponde di metterli in coerenza. Quando il pilota riesce, l’organizzazione scopre che il successo era la parte facile.

Governare un’implementazione di IA comincia quindi da una decisione poco spettacolare: indicare chi risponde dell’esecuzione e definire di che cosa risponde. Tutto il resto discende da lì.

Prioritizzare i casi d’uso sul costo di implementazione, non sulla novità

Un portafoglio credibile si costruisce su due assi: il valore operativo del risultato e il costo reale dell’implementazione — accesso ai dati, cambiamento di processo, integrazione, formazione e supervisione. La novità non è un criterio.

In pratica significa valutare ogni candidato con poche domande oneste: quale decisione o attività cambia; chi possiede i dati necessari; come si presenta il processo dopo l’adozione; chi verifica l’output; e cosa succede quando il modello sbaglia. I casi d’uso che non sanno rispondere alle ultime due domande non sono pronti, per quanto convincente sia stata la dimostrazione.

• Quale attività o decisione cambia concretamente
• Chi possiede i dati e ne autorizza l’uso
• Come si presenta il processo dopo l’adozione
• Chi verifica e accetta l’output
• Qual è la modalità di errore e chi se ne fa carico

Avviare i pilot con una condizione di uscita

Un pilota senza condizione di uscita diventa permanente. Prima di partire occorre concordare quale risultato giustificherebbe la scalabilità, quale risultato giustificherebbe l’interruzione ed entro quando la valutazione sarà espressa. Entrambe le risposte devono essere accettabili: un pilota che può solo avere successo non è una valutazione, è una decisione già presa.

La condizione di uscita va espressa in termini operativi — tempo di ciclo, tasso di errore, costo per pratica, volumi, qualità della revisione — e misurata rispetto alla baseline attuale. Se la baseline non è mai stata misurata, misurarla fa parte del pilota.

Trattare dati e accessi come percorso critico

In molte implementazioni di IA l’accesso ai dati, l’integrazione e la titolarità operativa pesano più della sola performance del modello. Ciò che conta è l’accesso: quali sistemi contengono i dati, chi ne autorizza l’uso, come vengono puliti e aggiornati e quali vincoli contrattuali o normativi si applicano.

Queste dipendenze appartengono al piano come voci con responsabile e data, non come ipotesi. Un pilota che ha lavorato in silenzio su un foglio esportato non ha dimostrato che la versione di produzione possa funzionare. Rendere esplicite le dipendenze sui dati fin dall’inizio riduce in misura rilevante i ritardi evitabili.

Pianificare l’adozione come esecuzione, non come comunicazione

L’adozione fallisce quando viene trattata come un annuncio. Le persone il cui lavoro cambia devono sapere cosa ci si attende da loro, di che cosa restano responsabili e dove il loro giudizio prevale ancora sul sistema.

Serve lavoro concreto: procedure aggiornate, responsabilità di verifica, formazione, un canale di supporto per le prime settimane e un ciclo di feedback che arrivi a chi mantiene la soluzione. Serve anche una posizione chiara sulla supervisione: quali output vengono controllati, da chi e come si registrano le eccezioni.

Riportare alla direzione nello stesso formato degli altri progetti

Le iniziative di IA traggono beneficio da un reporting identico a quello di ogni altra esecuzione: stato di avanzamento, milestone, rischi aperti, decisioni richieste e dipendenze a rischio. Il lessico specialistico non deve entrare nel reporting esecutivo: allo sponsor serve sapere se l’iniziativa è in linea e che cosa gli viene chiesto.

Uno stato breve e a cadenza fissa fa ciò che nessuna dimostrazione può fare: offre alla direzione una base continua per decidere se accelerare, sospendere o fermare, mentre la decisione costa ancora poco.

Il minimo di governance

Per la maggior parte delle organizzazioni la struttura adeguata è essenziale: un responsabile dell’esecuzione, una lista di casi d’uso prioritizzata, un pilota con condizione di uscita, un registro delle dipendenze che includa dati e accessi, un piano di adozione e uno stato di una pagina ogni due settimane. Nulla di specifico dell’IA: è esattamente per questo che funziona.