Valutare i casi d'uso dell'IA generativa senza partire dalla tecnologia

Partire dal problema, non dallo strumento

Il modo più comune per far naufragare un progetto di IA generativa è scrivere il caso d'uso partendo dal modello o dalla piattaforma già scelti: si ottiene una dimostrazione che funziona in laboratorio ma non entra in alcun processo aziendale. La guida di Databricks indica una metodologia a tappe per l'adozione: inventariare i dati proprietari, dare priorità a progetti pilota ad alto impatto e integrare l'IA nei flussi di lavoro esistenti invece di distribuirla come strumento autonomo. Le organizzazioni che agiscono su questi fronti, osserva la stessa fonte, realizzano valore molto più rapidamente di quelle che trattano l'IA come un singolo progetto tecnologico.

Databricks, citando il McKinsey Global Institute, stima per l'IA generativa un valore economico annuo tra 2,6 e 4,4 trilioni di dollari, con il 75% concentrato in quattro aree: operazioni sui clienti, marketing, ingegneria del software e ricerca e sviluppo. Goldman Sachs prevede un aumento del 7% del PIL globale attribuibile all'IA generativa e due terzi delle occupazioni statunitensi esposte a qualche forma di automazione. MIT Technology Review Insights, sempre citato da Databricks, rilevava che il 94% delle organizzazioni usava già l'IA in qualche forma, ma solo il 14% puntava a un'adozione a livello aziendale entro il 2025: la distanza tra sperimentazione diffusa e valore sistemico è il problema da risolvere.

Il criterio operativo è formulare il caso d'uso come una frase sul processo, non sulla tecnologia: quale attività, svolta da chi, con quali input e output, cambierebbe. Tre domande filtrano subito le candidature: chi è il proprietario del processo e cosa ci guadagna; quali dati servono e chi li controlla; come si riconosce, a fine trimestre, se ha funzionato. Se nessuna delle tre ha una risposta concreta, la discussione su modello, fornitore e architettura è prematura.

Valore economico stimato dell'IA generativa (fonte: Databricks)

Mappare processi e punti di attrito

Le capacità da cercare nei processi sono note e limitate. IBM elenca le applicazioni tipiche dell'IA generativa: trovare rapidamente insight nascosti in grandi quantità di testo non strutturato, automatizzare attività noiose e ripetitive, semplificare i flussi di lavoro generando contenuti personalizzati (descrizioni di prodotto, testi pronti al mercato) e progettare contenuti, campagne e prodotti che migliorano l'esperienza del cliente. Sono quattro categorie di punti di attrito da cercare nell'organizzazione.

La mappa parte dai depositi di testo non strutturato già esistenti: ticket di assistenza, e-mail dei clienti, verbali di riunione, note dei commerciali, contratti, documentazione tecnica, commenti delle recensioni. Per ciascun deposito si registrano volume, frequenza, tempo medio di lavorazione manuale e numero di persone coinvolte. Le attività ripetitive emergono da sole: riscrittura di risposte standard, riassunti di documenti lunghi, classificazione e instradamento di richieste, estrazione di dati da testi liberi.

Personalizzazione e supporto decisionale richiedono un passaggio in più. Nel primo caso il punto di attrito è un contenuto prodotto in serie da adattare a segmenti o singoli clienti; nel secondo è una decisione presa ogni volta da zero su informazioni disperse. In entrambi conviene annotare accanto al processo chi subisce l'attrito oggi, perché quella persona diventerà l'utente o il revisore del sistema e la sua adozione determina il risultato.

Inventario dei dati e condizioni di affidabilità

Databricks colloca tra le tre priorità che definiscono la prima fase di ogni percorso di IA generativa la costruzione dell'infrastruttura dati che rende affidabile l'IA, accanto alla selezione dei progetti pilota e ai framework di governance. L'inventario deve rispondere a domande verificabili: dove risiedono i dati necessari al caso d'uso, in quale formato, chi ne è titolare, chi ha il diritto di usarli per questo scopo, con quale frequenza si aggiornano e con quale qualità. Un caso d'uso che dipende da dati non accessibili, duplicati in tre sistemi o privi di un proprietario chiaro non è maturo, qualunque sia l'idea.

Il passaggio successivo riguarda sensibilità e luogo di trattamento. Occorre classificare i dati per contenuto personale o riservato, verificare i vincoli contrattuali con i fornitori, stabilire se il trattamento avviene in ambienti controllati dall'organizzazione e come vengono registrati gli accessi. Se il caso d'uso richiede dati che non possono uscire da un perimetro governato, il vincolo va scritto subito nel perimetro del progetto, non scoperto in fase di collaudo.

In Italia il tema è esplicito. La bozza di Linee Guida per lo sviluppo di sistemi di Intelligenza Artificiale nella pubblica amministrazione, pubblicata da AGID in consultazione pubblica dal 12 marzo all'11 aprile 2026, dedica capitoli specifici all'architettura logica di riferimento (orchestratore, modelli, dati e tool), al ciclo di vita dei sistemi, alla sicurezza cibernetica e alla neutralità hardware, acceleratori e portabilità. In un commento alla consultazione si propone di valorizzare le architetture in cui i dati restano interamente all'interno dell'infrastruttura dell'amministrazione o in ambienti comunque governati dall'ente, indicando come vantaggi privacy, protezione delle informazioni, controllo sul trattamento e riduzione dell'esposizione verso servizi esterni. È la posizione di un partecipante, non un requisito definitivo, ma mostra che il luogo di trattamento dei dati è un criterio di fattibilità del caso d'uso, non un dettaglio implementativo.

Criteri per priorizzare: impatto, ROI, fattibilità e rischio

Databricks raccomanda di selezionare progetti pilota ad alto impatto con ROI chiaro e di costruire framework di governance che proteggano i dati sensibili e mantengano la conformità alle normative. Da qui una griglia a cinque colonne per confrontare i candidati: valore atteso annuo, tempo per arrivare al primo risultato misurabile, dipendenze tecniche (dati, integrazioni, accessi), rischio operativo in caso di output errato e reversibilità della scelta.

La stima del valore atteso si costruisce con tre fattori dichiarati apertamente: volume annuo delle attività coinvolte, tempo medio per attività e quota realistica di lavoro che il sistema può assorbire al netto della revisione umana. Il prodotto dei tre dà un ordine di grandezza da confrontare con il costo di sviluppo e di esercizio. Se la quota di lavoro assorbibile non è argomentabile con dati interni, il numero va presentato come ipotesi da verificare nel pilota, non come previsione.

Il tempo al valore è il criterio che più spesso esclude candidati altrimenti attraenti: un caso d'uso che richiede la bonifica di più sistemi dati prima di produrre qualsiasi output va collocato dopo un pilota più rapido, anche se il valore potenziale è superiore. La sequenza tipica è: pochi piloti indipendenti sulla stessa infrastruttura dati, misurazione dei risultati, poi estensione a processi adiacenti. Un perimetro troppo ampio al primo tentativo rende impossibile capire quale componente ha funzionato.

Valutare il caso d'uso dentro il flusso di lavoro

Il criterio già richiamato — integrare l'IA nei flussi di lavoro esistenti anziché distribuirla come strumento autonomo — ha una conseguenza operativa diretta: uno strumento separato che l'utente deve aprire, alimentare manualmente e di cui deve ricopiare l'output in un altro sistema aggiunge passaggi invece di eliminarli, e la sua adozione crolla appena finisce l'entusiasmo. La valutazione del caso d'uso deve quindi contare i passaggi prima e dopo l'introduzione del sistema.

Nel disegno del flusso va stabilito chi rivede l'output e con quanto tempo a disposizione, e cosa succede quando il revisore non è d'accordo. Se la revisione richiede più tempo di quanto il sistema ne faccia risparmiare, il caso d'uso va ridimensionato a un'attività con output a basso rischio.

Il terzo elemento è l'attrito per l'utente: numero di clic o passaggi aggiunti, necessità di riformulare richieste, tempo di attesa percepito, frequenza con cui l'output va corretto. Un caso d'uso con valore teorico alto ma attrito alto viene abbandonato dall'utente prima di produrre benefici misurabili, e la metrica di adozione lo rileva prima di qualsiasi analisi di ROI.

Esempi di casi d'uso per funzione

Le aree in cui si concentra la maggior parte del valore, già richiamate sopra, restano il riferimento principale; tra le funzioni con casi d'uso già convincenti la stessa fonte cita anche l'assistenza clienti e la catena di approvvigionamento. Ragionare per funzione aiuta a tradurre capacità generiche in problemi riconoscibili dai responsabili di reparto.

Nelle operazioni sui clienti e nell'assistenza il problema di partenza è il tempo speso a leggere, classificare e rispondere a testi liberi: richieste ripetute, storico delle interazioni, reclami. Il valore atteso è la riduzione del tempo per pratica e l'aumento della coerenza delle risposte, con revisione umana sui casi che modificano il rapporto contrattuale. Nel marketing il problema è la produzione di contenuti in serie — descrizioni di prodotto, varianti per canale, testi di campagna — e il valore atteso è il tempo di produzione per contenuto insieme alla possibilità di testare più varianti; IBM colloca esplicitamente in questa categoria la creazione di contenuti personalizzati e di campagne.

In ingegneria del software il punto di attrito è la documentazione di codice esistente, la scrittura di test, la spiegazione di codice altrui e la risposta a domande ricorrenti sul repository: il valore si misura in tempo di onboarding e in difetti intercettati prima del rilascio. In ricerca e sviluppo il problema è la sintesi di letteratura, brevetti e report interni; in supply chain è la gestione di documenti, fornitori e comunicazioni operative, dove il valore sta nel ridurre il tempo di verifica e nel far emergere anomalie. In tutte queste aree il caso d'uso si descrive senza nominare alcuna piattaforma: prima il problema e la metrica, poi lo strumento.

Rischi, governance e revisione umana

Per ogni caso d'uso vanno elencati i rischi specifici prima di stimare i benefici. Databricks cita tra le pratiche di IA responsabile il RAG per ridurre le allucinazioni e la revisione umana per le decisioni critiche, e indica tra le tre priorità iniziali la costruzione di framework di governance che proteggano i dati sensibili e mantengano la conformità alle normative. La bozza di Linee Guida AGID per la PA dedica un capitolo alla sicurezza cibernetica, segnalando che in questi sistemi il rischio non dipende solo dall'identità dell'utente o dal ruolo applicativo ma anche dal livello di fiducia dei contenuti trattati.

Le categorie di rischio da verificare caso per caso sono cinque: output plausibile ma errato (allucinazione) su contenuti che qualcuno userà per decidere; trattamento di dati personali o riservati fuori dai limiti autorizzati; uso del sistema in una decisione che produce effetti giuridici o economici su una persona; mancanza di tracciabilità di come è stato prodotto un output; esposizione della superficie di attacco, inclusi accessi e integrazioni. Per ciascuna va indicata la mitigazione e chi la presidia.

Sul piano organizzativo, Databricks indica team interfunzionali e un Centro di Eccellenza come strumenti per governare le scelte. In pratica significa assegnare tre responsabilità distinte: chi possiede il processo e risponde del risultato operativo, chi possiede i dati e ne autorizza l'uso, chi possiede il sistema e ne garantisce il funzionamento e la conformità. Un caso d'uso senza un nome per ciascuno di questi tre ruoli non è pronto per il rilascio.

Scegliere l'architettura dopo il caso d'uso

Le scelte di architettura — modello ospitato o locale, soluzione proprietaria o software libero, deployment ibrido — diventano valutabili solo dopo aver fissato processo, dati, rischi e metriche, perché sono i requisiti non funzionali del caso d'uso a decidere. Tra questi: dove possono stare i dati, quale latenza è accettabile, quanto conta la portabilità tra fornitori, quale resilienza serve se un servizio esterno non è disponibile, quale riduzione del lock-in si vuole ottenere.

Il contesto italiano offre un riferimento esplicito. La bozza di Linee Guida AGID in consultazione include un capitolo su neutralità hardware, acceleratori e portabilità dei sistemi di IA; nel commento già citato si propone di valorizzare architetture locali, modulari e basate su software libero come modello di interesse per la Pubblica Amministrazione, con l'esempio di server Ubuntu LTS, LLM locali leggeri, applicazioni in Python distribuite tramite Flask e integrazione con strumenti open source come LibreOffice. Lo stesso commento collega questa impostazione a trasparenza, qualità dei processi, centralità dell'uomo, cybersicurezza, resilienza, accessibilità universale, portabilità e riduzione del lock-in tecnologico. Sono criteri riutilizzabili anche fuori dalla PA, come lista di verifica da applicare a qualsiasi proposta di architettura.

La conseguenza pratica è che la gara tra soluzioni va impostata su requisiti verificabili — dove risiedono i dati, come si esportano, cosa succede se il fornitore cambia condizioni, quanto costa l'uscita — e non su confronti di qualità dei modelli, che cambiano più rapidamente dei processi che devono servire.

Metriche e ROI per capire se funziona

Le metriche vanno definite prima del rilascio, insieme al caso d'uso, e ancorate a una baseline misurata: tempo medio per attività, volume mensile, tasso di rilavorazione o errore, costo per unità di lavoro, tempo di risposta al cliente. Senza baseline qualsiasi miglioramento dichiarato è indimostrabile, e il pilota non produce alcuna decisione di scala.

Il set di indicatori operativi copre cinque famiglie: tempo risparmiato per attività, qualità dell'output (valutata da chi lo usa, non solo dal team di progetto), riduzione degli errori o delle rilavorazioni, adozione effettiva da parte degli utenti previsti, soddisfazione degli utenti interni o dei clienti finali. A queste si aggiunge il costo per attività, che tiene conto non solo dell'esercizio del sistema ma anche del tempo di revisione umana richiesto.

Databricks collega la selezione dei piloti a un ROI chiaro; il modo per renderlo verificabile è confrontare, a fine pilota, la variazione delle metriche rispetto alla baseline con il costo complessivo sostenuto. La metrica di adozione va letta per prima: un caso d'uso con ottimi risultati sulle altre dimensioni ma con utilizzo sporadico segnala un problema di integrazione nel flusso di lavoro, non un problema di modello.

Checklist operativa per valutare un caso d'uso

Problema: quale attività, svolta da chi, con quali input e output, cambierebbe; chi è il proprietario del processo e cosa ci guadagna. Dati: dove risiedono, chi li autorizza, con quale qualità e frequenza si aggiornano, se contengono dati personali o riservati, in quale ambiente vengono trattati. Workflow: quanti passaggi si eliminano rispetto a oggi, dove si inserisce l'output, quanto attrito aggiunge all'utente, chi rivede e in quanto tempo.

Rischio: cosa succede se l'output è plausibile ma sbagliato, se il sistema tocca una decisione critica, se i dati escono dal perimetro autorizzato, come si traccia la provenienza di un output. Metrica: quale baseline è misurata oggi, quali KPI operativi si monitorano (tempo, qualità, errori, adozione, soddisfazione, costo per attività) e con quale soglia il pilota si considera riuscito o da chiudere.

Integrazione: il sistema entra in uno strumento già usato o resta un'applicazione separata; quali dipendenze tecniche servono e chi le possiede. Governance: quali ruoli sono assegnati per processo, dati e sistema, quale revisione umana è prevista, come si documentano le scelte. Architettura: dove stanno i dati, come si esportano, quale portabilità e resilienza sono richieste, quanto costa uscire dalla soluzione scelta. Responsabilità: chi risponde dell'output finale verso il cliente, l'utente interno o l'autorità di controllo. Se manca una di queste risposte, il caso d'uso non è ancora pronto per essere sviluppato.