L’AI in azienda non fallisce nel modello, ma nel sistema

Per introdurla davvero, o per capire perché un progetto già avviato non stia mantenendo le attese, bisogna leggere l’intera pipeline di deployment: obiettivi, evidenze, orchestrazione, front end, responsabilità, osservabilità e apprendimento dopo il rilascio.

di Andrea Viliotti - Framework GDE

Perché i progetti AI in azienda falliscono

Quando un’azienda mi chiede una consulenza strategica per introdurre l’AI, oppure mi coinvolge per capire perché un progetto già partito non stia producendo il valore promesso, non comincio quasi mai dal modello. Comincio dall’impresa. Dalla domanda che vuole risolvere, dai processi che vuole toccare, dai vincoli che non può eludere, dalle responsabilità che restano in capo al management e dal contesto operativo in cui quella tecnologia dovrà funzionare ogni giorno, non solo in una demo.

È esattamente da questa esperienza che nasce il paper From Concept to Release: An Observer-Dependent Pipeline Model for Generative AI Systems with Conversational Front Ends. Ho cercato di fare un passo che, a mio avviso, oggi manca spesso nel dibattito manageriale: trasformare una pratica consulenziale company-first in una architettura teorica abbastanza rigorosa da essere falsificabile, ma anche abbastanza leggibile da aiutare chi deve decidere, investire e rispondere dei risultati. Non una formula magica, e nemmeno un nuovo slogan sull’AI, ma una bussola per leggere meglio i progetti.

Il punto di partenza è semplice. Una soluzione di Generative AI con interfaccia conversazionale non coincide né con il modello, né con il chatbot. È una pipeline. E il suo esito dipende dalla coerenza dell’intera pipeline, non dalla brillantezza di un singolo componente. Possiamo avere un backend tecnicamente forte, ma un front end inadatto agli utenti reali. Possiamo avere una conversazione fluida, ma un regime di evidenze fragile, con fonti poco tracciabili e output difficili da ricostruire. Possiamo avere policy ben scritte, ma escalation che nella pratica non funzionano. E possiamo perfino credere che il sistema stia peggiorando, quando in realtà sta diventando solo più osservabile.

Il problema non è il chatbot

Questa, per me, è la vera soglia manageriale da superare. Finché l’AI viene letta come “scelta del modello” o come “esperienza del chatbot”, il rischio è prendere per solido ciò che è soltanto convincente. Nel paper propongo di spostare il fuoco sull’oggetto reale dell’analisi: la pipeline observer-dependent, cioè un sistema sociotecnico il cui stato diventa comprensibile solo se si guarda anche a come viene osservato, governato, misurato e corretto nel tempo.

Figura — Mappa concettuale semplificata della pipeline: la coerenza si gioca nei passaggi, non nel singolo componente.

La differenza non è teorica in senso astratto. È pratica. Se un progetto fallisce, il problema può nascere nel concept, prima ancora che nella tecnologia. Può nascere nella qualità delle evidenze, se le fonti non sono abbastanza coperte, verificabili o ricostruibili. Può nascere nel backend, nell’orchestrazione che collega strumenti e retrieval, nel front end che incontra utenti diversi con esigenze diverse, nella missione che si allarga senza disciplina, nella sicurezza che rincorre il prodotto invece di accompagnarlo, nell’osservabilità che non distingue tra rischio strutturale e ciò che semplicemente riusciamo a vedere meglio. Il successo o il fallimento non si giocano in un punto solo: si giocano nella coerenza, o nell’incoerenza, dei passaggi.

Ed è anche per questo che nel paper insisto su una distinzione che nel mondo aziendale diventerà sempre più importante. Non tutti gli utenti chiedono la stessa cosa a un’interfaccia conversazionale. Ci sono contesti in cui l’utente cerca orientamento, esplorazione, inquadramento del problema. E ci sono contesti in cui cerca una risposta delimitata, una comparazione affidabile, una soluzione che possa essere usata o almeno escalata senza ambiguità. Un sistema può sembrare eccellente nel primo scenario e rivelarsi debole nel secondo. Se noi leggiamo tutto con metriche aggregate, perdiamo proprio l’asimmetria che conta di più.

Qui entra un altro equivoco molto diffuso: l’antropomorfismo. Una conversazione ben costruita può far apparire il sistema esperto, rassicurante, persino autorevole. Ma la salienza conversazionale non trasferisce la responsabilità alla macchina. Nel paper il chatbot resta un livello relazionale terminale della pipeline, non un soggetto normativo. Questo passaggio, che a qualcuno può sembrare ovvio, in realtà non lo è affatto quando un progetto entra nei processi aziendali. Perché più l’interfaccia appare naturale, più cresce il rischio che il management, gli operatori o gli utenti spostino implicitamente sul sistema una quota di fiducia che non è stata ancora guadagnata dall’intera architettura.

Dove si spezza la coerenza

Per un’impresa, allora, la domanda giusta non è: “quanto è bravo il modello?”. La domanda giusta è: “questa pipeline regge il problema che le sto affidando?”. Regge in fase di concept? Regge quando deve collegare output e fonti? Regge nel passaggio tra backend e interfaccia? Regge quando deve mantenere coerenza tra missione, sicurezza, escalation e controllo umano? Regge quando entra in un contesto reale, con utenti reali, pressioni reali e tempi reali? E soprattutto: regge nel tempo, cioè dopo il rilascio, quando serve apprendere da errori, near miss, feedback, revisioni e patch?

Nel paper chiamo questo snodo lifecycle coherence. A me interessa molto perché sposta la valutazione dall’effetto vetrina alla capacità di tenuta. Un progetto può apparire forte e invece essere fragile. Può sembrare debole e invece stare migliorando, perché ha appena aumentato logging, tracciabilità e revisione umana. Se non distinguiamo il rischio strutturale dal rischio osservato, finiamo per leggere i dashboard in modo ingenuo: più incidenti visibili uguale sistema peggiore. Ma non è sempre così. In alcuni casi stiamo solo vedendo meglio ciò che prima restava nascosto.

Questo ha conseguenze dirette sia per chi introduce l’AI da zero sia per chi deve fare audit su un’iniziativa già avviata. Nel primo caso, la tentazione più frequente è partire dalla tecnologia e “appoggiarle sopra” il resto. Nel secondo, la tentazione è cercare un colpevole unico: il modello, il team, il fornitore, l’interfaccia, i dati. In entrambi i casi si rischia di perdere la struttura del problema. Una introduzione ex novo funziona meglio quando il disegno parte dall’uso, dai criteri di escalation, dal regime delle evidenze, dal livello di osservabilità e dal ciclo di apprendimento post-release. Un audit serio funziona meglio quando ricostruisce la catena e identifica dove la coerenza si interrompe.

Faccio un esempio astratto, che vedo spesso. Un’azienda lancia un assistente interno e scopre che gli utenti lo giudicano utile nelle interazioni esplorative, ma lo evitano nelle richieste più vincolanti. Se si guarda solo la soddisfazione media, il progetto sembra andare bene. Se invece si separano i due stati d’uso, emerge un’altra diagnosi: la conversazione è gradevole, ma il sistema non è ancora abbastanza robusto quando il bisogno diventa decision-adjacent. In un altro caso, il problema non è affatto nel modello, bensì nell’orchestrazione: retrieval incompleto, uso degli strumenti instabile, percorsi di escalation formalmente previsti ma operativamente deboli. In un altro ancora, la missione è stata definita in modo troppo esteso rispetto alla maturità di sicurezza e controllo. Sono guasti diversi. Eppure, senza una lettura di pipeline, tendono a essere confusi.

Una bussola per decidere meglio

Per questo dico che il valore del framework è duplice. Da un lato è uno strumento di lavoro per chi progetta, valuta o corregge sistemi di GenAI conversazionale. Dall’altro è uno strumento di comprensione manageriale. Serve a dare al management un linguaggio meno ingenuo e meno dipendente dalla demo. Non bisogna essere tecnici per capire che un progetto AI può rompersi nel passaggio tra promesse, dati, orchestrazione, front end e governance. Bisogna però avere una mappa chiara di dove guardare e di quali domande fare prima di scambiare la fluidità per affidabilità.

Anche il limite del paper, del resto, è dichiarato con chiarezza. Non propongo un motore predittivo già calibrato in senso forte. Non dico che l’ODPM abbia già vinto la competizione con tutti i framework alternativi. Dico qualcosa di più sobrio e, secondo me, più utile: oggi abbiamo bisogno di una architettura formalizzata e contestabile che renda leggibile il deployment, che espliciti i falsificatori, che separi meglio rischio strutturale e rischio osservato, e che consenta di capire perché sistemi apparentemente forti possano rivelarsi deboli quando entrano davvero nei processi. Se questa architettura, nel tempo, non produrrà un surplus diagnostico rispetto a letture più semplici, allora non avrà meritato la sua complessità. Ma la domanda va posta così, non aggirata.

Per le imprese il punto finale è molto concreto. L’AI crea valore quando smette di essere una promessa astratta e diventa una capacità leggibile, governabile e migliorabile. Questo significa partire dal problema d’impresa, definire bene il perimetro, costruire un regime serio di evidenze, progettare l’orchestrazione come un livello autonomo e non come un dettaglio tecnico, distinguere gli usi esplorativi da quelli che richiedono risposte vincolanti, chiarire dove resta la responsabilità umana, investire in osservabilità e trattare il post-release learning come una parte del sistema, non come una manutenzione accessoria. Quando lavoro su un progetto AI, è da qui che comincio. E sempre più spesso è qui che, nei progetti già avviati, torno per capire dove si è inceppata la macchina.