Prima del pilota: come scegliere i casi d’uso AI che meritano un investimento

La lista delle idee non è ancora una priorità

Riassumere documenti, preparare preventivi, prevedere abbandoni, assistere il customer care: una discussione sull’AI produce facilmente una lunga lista. È una fase utile, perché rende visibili frizioni che le persone avevano imparato a sopportare. Il problema arriva quando ogni funzione si affeziona alla propria proposta e la direzione deve distribuire risorse limitate.

La mia curiosità tecnologica mi porterebbe a provare molto. Nel decidere un investimento, però, cerco un’altra disciplina: quale incertezza importante potremo ridurre e quale cambiamento operativo renderà utile il risultato? Una demo gradevole può essere un pessimo primo progetto se dipende da dati irraggiungibili o da un processo che nessuno vuole modificare.

Prima di scegliere uno strumento, descriverei attività, frequenza, persone coinvolte e risultato attuale. “Vorremmo un agente” non basta. “Ogni richiesta di preventivo richiede la ricerca di condizioni in tre archivi e una verifica finale del commerciale” permette già di osservare tempi, errori e vincoli.

Chiederei poi un campione rappresentativo, inclusi casi difficili e richieste incomplete. Misurare soltanto il lavoro semplice produce una promessa che si rompe appena il servizio incontra il cliente reale. La baseline deve includere anche il tempo di revisione: se l’output arriva in trenta secondi ma richiede venti minuti di correzione, l’orologio non si è fermato dopo la generazione.

Quattro dimensioni, senza una falsa precisione

Userei una scheda con quattro dimensioni: valore operativo, fattibilità dei dati, possibilità di adozione, conseguenze dell’errore. Per ciascuna registrerei evidenza e incertezza. Un voto da uno a cinque può aiutare il confronto, ma non rende equivalenti rischi molto diversi. Una criticità non accettabile sugli accessi non si compensa con un buon punteggio di convenienza.

Il NIST AI RMF offre un riferimento per contestualizzare e misurare il rischio. La scheda qui proposta è una mia traduzione operativa per la selezione dei progetti, non una procedura prescritta dal NIST.

Un conto economico che regga alla revisione

Immaginiamo, solo per fare i conti, 600 pratiche mensili e sei minuti netti risparmiati su ciascuna: sono 60 ore, non automaticamente 60 ore di costo eliminate. Se stimiamo 30 euro l’ora, otteniamo 1.800 euro di capacità teorica mensile. Il beneficio dipenderà da come quella capacità sarà utilizzata. L’esempio non è un benchmark né un risultato cliente.

Nel conto inserirei integrazione, licenze, consumo delle API, controlli, formazione, assistenza e manutenzione. Anche un progetto con consumo modesto può richiedere molto lavoro per mantenere aggiornate le fonti. Conviene separare investimento iniziale, costo mensile e costo per pratica completata correttamente.

Per una previsione commerciale, invece, il confronto sarà con un metodo semplice già utilizzabile: una regola, una media storica o la procedura corrente. Il modello più sofisticato deve giustificare il proprio costo incrementale, non soltanto battere l’assenza di qualsiasi metodo.

Un portafoglio di opportunità, non una gara di entusiasmo

Tre funzioni possono proporre progetti molto diversi: marketing vuole accelerare la produzione dei contenuti, amministrazione cerca supporto nella lettura dei documenti, commerciale chiede previsioni più affidabili. Confrontarli soltanto sulle ore risparmiate può favorire il compito più facile da contare. Confrontarli sull’importanza percepita può favorire chi ha più peso nella riunione.

Separerei perciò valore atteso e qualità dell’evidenza. Un progetto può avere un beneficio potenziale grande ma poco dimostrato; un altro un beneficio più limitato e ben osservabile. Il primo può meritare una piccola esplorazione, il secondo un investimento operativo. Non devono necessariamente competere per la stessa fase e lo stesso budget.

Questo permette anche di evitare un equivoco: chiedere a un esperimento la prevedibilità di un acquisto standard. Per un’attività esplorativa finanzio una domanda e un limite di esposizione. Per un’estensione finanzio un risultato sostenuto da evidenze. La documentazione e il livello di controllo cambiano con la maturità della decisione.

Una matrice utile potrebbe distinguere quattro destinazioni: avviare un test, preparare dati e processo, rinviare con una ragione, scartare. La seconda è particolarmente importante. Un caso d’uso può essere valido e arrivare nel momento sbagliato: senza accessi, definizioni o responsabile non migliora perché compriamo prima la tecnologia.

La qualità del controfattuale

Per capire il valore dobbiamo immaginare che cosa accadrebbe senza il progetto. Non basta confrontare il nuovo sistema con la versione peggiore del lavoro corrente. Potremmo ottenere una parte del beneficio cambiando un modulo, chiarendo una procedura o automatizzando una regola. Quel confronto evita di attribuire al modello il valore di una semplificazione che non dipende dall’AI.

Nel preventivo, per esempio, una buona base documentale può già ridurre la ricerca. Un assistente può aggiungere capacità di interpretazione, ma il suo contributo incrementale va distinto. È una valutazione che tutela l’investimento: se il processo migliora prima dell’AI, avremo una base più forte anche per il passo successivo.

Quando è praticabile, osserverei un gruppo o un periodo di confronto con caratteristiche simili. Dove non lo è, documenterei le differenze: volumi, stagionalità, persone e complessità. Non ogni PMI può realizzare un esperimento controllato rigoroso, ma può evitare di chiamare causalità una coincidenza favorevole.

Anche il costo dell’errore richiede un confronto. Una prima bozza di contenuto errata e una variazione di prezzo errata non hanno lo stesso impatto. La valutazione deve considerare probabilità, rilevabilità e possibilità di recupero. L’esistenza di un revisore non azzera il rischio se quel revisore ha pochi secondi e nessuna fonte da consultare.

Che cosa chiedere nella proposta del fornitore

Vorrei un perimetro di prova, dati richiesti, risultati attesi e responsabilità. Chiederei come vengono gestiti aggiornamenti del modello, errori, accessi e cancellazione dei dati. La proposta dovrebbe chiarire che cosa rimane utilizzabile se la collaborazione finisce: documentazione, integrazioni e materiali di valutazione sono patrimonio del progetto.

Sul prezzo distinguerei la fase iniziale dall’esercizio. Un canone prevedibile può essere utile, ma deve rendere leggibili limiti di utilizzo, costi variabili e attività escluse. Il tempo interno è una voce reale: persone che selezionano esempi, verificano risultati e formano colleghi stanno contribuendo all’investimento.

Farei poi una domanda poco comoda: in quali condizioni il fornitore consiglierebbe di non procedere? Una risposta precisa può essere un segnale di maturità. Una promessa che non prevede casi inadatti lascia all’impresa il compito di scoprirli dopo aver acquistato.

Infine, assegnerei una persona che possa cambiare il processo. Un referente che raccoglie feedback ma non ha alcuna autorità rischia di diventare il custode di una lista di problemi. Il pilota deve poter modificare un passaggio, una regola o una responsabilità quando l’evidenza lo richiede. Altrimenti stiamo testando una tecnologia dentro un’organizzazione che ha già deciso di non cambiare.

Il portafoglio richiede anche una riserva di capacità. Se tutti i progetti partono insieme, gli stessi responsabili diventano un collo di bottiglia per dati, verifiche e adozione. La priorità deve quindi tradursi in una sequenza: quale iniziativa prepara le condizioni per la successiva e quale può aspettare senza perdere valore? Finanziare meno prove contemporaneamente può rendere più rapida la decisione complessiva, perché consente di seguirle fino a un esito utilizzabile.

Il pilota deve lasciare una decisione

Definirei prima dell’avvio il perimetro, la durata, il responsabile e le condizioni per procedere. Servono almeno una misura del risultato, una della qualità e una dell’adozione. Scegliere le soglie dopo aver visto i dati invita ad accomodare la valutazione a ciò che è andato bene.

Un esito negativo può essere prezioso se costa poco e chiarisce un limite. Più difficile è il pilota che resta acceso per mesi, produce qualche episodio interessante e non trova mai una decisione. Occupa attenzione, consuma budget e mantiene le persone in un assetto provvisorio.

Il primo investimento dovrebbe quindi comprare anche conoscenza organizzativa: capire se i dati sono governabili, se gli utenti si fidano con buone ragioni e se qualcuno sa gestire gli errori. Io partirei dal progetto che consente di imparare questo con un rischio sostenibile. L’ambizione viene dopo, quando abbiamo qualcosa di più solido di una dimostrazione da mostrare.