Cosa fare e cosa non fare con l’AI in azienda
AI non è una commodity: per usarla in modo proficuo bisogna conoscerla e saperla adottare.
Il post in tre frasi
Molte aziende si avvicinano all’AI partendo dallo strumento (un fornitore, un modello, una tecnologia) anziché dal problema da risolvere, e per questo si scontrano con costi imprevisti e risultati che non tornano.
I nove punti che seguono, ciascuno con un fare e un non fare, coprono le principali scelte tecniche, organizzative ed economiche che guidano un processo di adozione di GenAI.
Non eliminano i rischi dell’adozione: aiutano a giungere alla decisione con meno assunzioni implicite e a ridurre il rischio di fallimento.
Quando un’azienda mi parla di GenAI, la prima domanda è quasi sempre la stessa: “Da dove cominciamo?” La intendono in senso operativo: scegliere un caso d’uso, un fornitore, un pilota da chiudere entro il trimestre.
Il 9 giugno ho parlato a Bologna con un gruppo di imprese manifatturiere che stanno cercando di capire come gestire l’adozione di GenAI nei propri processi. L’intervento era in due parti: la prima sui limiti strutturali degli LLM, la seconda è un framework con nove punti su come impostare un’adozione pragmatica, ciascuno definito da un fare e un non fare.
I punti derivano da osservazioni raccolte tra aprile e maggio in quattro post su A bassa voce: L’agente che non sa perché, Quando il computer “indovina” e quando calcola, Per un martello, il mondo è fatto solo di chiodi, L’AI che non ricorda. Preparare l’intervento mi ha costretto a estrarne un framework operativo. Eccolo.
1. Partire dal problema, non dallo strumento
La domanda “come uso GenAI?” pone lo strumento prima del bisogno. La domanda corretta è l’opposto: qual è il problema da risolvere e quale strumento lo risolve al meglio? A volte sarà GenAI, spesso sarà altro. Sistemi esperti, blockchain e metaverso sono stati adottati con la stessa dinamica: prima la tecnologia, poi la ricerca di un caso d’uso che la giustificasse. Il risultato: molti studi e progetti mai arrivati in produzione.
✅ Partire da un problema specifico per cui esistono già dati sufficienti. Qualificarlo, poi valutare lo strumento.
❌ Non partire dallo strumento. Non trattare la GenAI come un'opzione automatica. Soprattutto, non trattarla come una commodity (un tema su cui tornerò presto).
2. Domain expert nel progetto, formazione in parallelo
Un LLM non conosce l’impresa specifica in cui deve essere adottato: vincoli operativi, limiti regolatori, procedure interne, conoscenza di dominio. Questa lacuna non si colma solo con più training. La conoscenza organizzativa cambia nel tempo, presenta contraddizioni interne e va arricchita e verificata da chi la usa ogni giorno. Allo stesso tempo, usare GenAI richiede di conoscerne le caratteristiche, i limiti e le dinamiche d’uso.
✅ Domain expert nel team dal giorno uno, con formazione parallela in GenAI fin dalla fase di costruzione del pilota.
❌ Non aspettarsi che un modello, solo perché più grande o potente, sia in grado di “imparare a conoscere l’azienda”. Non rimandare la formazione a dopo il pilota: è una precondizione, non una conseguenza.
3. Calcolare o stimare
Un foglio Excel calcola: stesso input, stesso output. Un LLM stima: pondera le probabilità e può cambiare risposta a parità di domanda. Trattare l’uno come l’altro non è una svista teorica: si paga con errori a valle, con controlli di riproducibilità che non tornano, con numeri che non stanno più insieme.
✅ Prima di scegliere lo strumento, chiarire il tipo di risposta necessario. Certezza riproducibile → calcolo deterministico. Stima, approssimazione, creazione → GenAI.
❌ Non usare GenAI come motore computazionale per calcoli o procedure che richiedono esattezza e riproducibilità dei risultati.
4. Nei workflow regolati, l’LLM è una scelta architetturale onerosa
Al vincolo del punto 3 se ne aggiunge un altro: la ricostruibilità delle decisioni. Nei processi con audit, tracciabilità, accountability legale e vincoli normativi, ricostruire ex post perché una decisione sia stata presa non è opzionale. Un LLM, come motore decisionale, rende quella ricostruzione strutturalmente difficile: le tracce di ragionamento che produce non costituiscono una garanzia di fedeltà al processo interno che ha portato alla decisione.
✅ Nei workflow regolati, mantenere il motore decisionale deterministico. L’LLM può agire come interfaccia con l’utente o come orchestratore di strumenti di terze parti, ma non decide.
❌ Non delegare a un agente non deterministico decisioni che devono essere ricostruibili di fronte a un auditor. Il livello di governance (control plane) può vincolare ciò che un agente è autorizzato a fare, non il modo in cui ragiona per farlo.
5. Nei sistemi transazionali, l’LLM sta fuori dal motore
I sistemi OLTP (contabilità, fatturazione, ERP, gestione degli ordini) hanno due requisiti tecnici che un LLM non è progettato per garantire: correttezza e prestazioni. Un saldo, una fattura, un movimento contabile non ammettono approssimazioni né errori di sincronizzazione tra le operazioni: la correttezza è al centesimo. E una transazione va chiusa in millisecondi, con migliaia di operazioni al secondo, a un costo unitario sostenibile. Nessuno di questi requisiti è compatibile con l’attuale profilo tecnico ed economico degli LLM di frontiera, tipicamente considerati nei progetti aziendali di GenAI attuali.
✅ Nei sistemi transazionali, tenere l'LLM fuori dalla catena delle transazioni. Ha senso come interfaccia esterna: interrogare un database in linguaggio naturale, generare report, sintetizzare dati. Il calcolo e la scrittura restano al motore deterministico.
❌ Non usare l’LLM come componente della catena transazionale, nemmeno come orchestratore di una sequenza di operazioni di commit (l’operazione che rende definitive e permanenti le modifiche di una transazione). Latenza, costi e non-determinismo cumulati rendono il servizio insostenibile prima ancora che inesatto.
6. Lo stato esterno ha un costo che va stimato
Gli LLM sono stateless per definizione: ogni sessione parte da zero. Per simulare la continuità, si costruisce uno stato esterno: un file di contesto, RAG, tecniche di context engineering (cioè come si struttura ciò che viene passato al modello a ogni chiamata). In un workflow personale funziona. In un processo aziendale, lo stato deve essere costruito, mantenuto in vita, validato e testato. È lì che la complessità esplode.
✅ Valutare il costo totale per gestire lo stato esterno: costruzione, manutenzione, validazione, test e riproducibilità.
❌ Non assumere che aggiungere RAG (un livello software che consente all’LLM di accedere a documenti specifici al momento della richiesta) risolva l’assenza di stato a un costo trascurabile. Il più delle volte costa più del processo deterministico che voleva sostituire, e funziona peggio.
7. Governance dei dati prima della governance dell’AI
Qualità, tagging, integrazione, accesso: senza “igiene dei dati”, ogni difetto entra nel modello e ne esce moltiplicato. Un progetto AI eredita tutti i problemi che il sistema informativo aziendale ha lasciato in sospeso: dati duplicati, incoerenze tra le fonti, campi non validati, accessi non tracciati. Non è un problema che si aggira scegliendo un modello migliore. La catalogazione delle fonti, la tracciabilità di chi le aggiorna, la definizione di misure di qualità e il controllo degli accessi vanno impostati prima, non dopo.
✅ Costruire la governance dei dati prima di avviare qualsiasi progetto di AI. Se non esiste, è il primo investimento — e va misurato, non solo dichiarato.
❌ Non lanciare un progetto AI se i dati a supporto non esistono o se non c’è un piano credibile per produrli e validarli. Non aspettarsi che il modello “recuperi” ciò che manca a monte.
8. Economia del progetto: costruzione ed esercizio
I costi dell’AI si dividono in due categorie con logiche distinte. Il costo di costruzione (build) va giustificato ex ante. GenAI non è, di per sé, più conveniente di un’alternativa tradizionale: per i compiti computazionali strutturati, un sistema deterministico ben progettato costa spesso meno e funziona meglio. Il costo di esercizio (run) è variabile e, senza un controllo dedicato, cresce rapidamente e in modo non lineare con l'uso. La FinOps Foundation propone un ciclo in tre fasi da adottare fin dall'inizio: Inform (visibilità), Optimize (efficienza), Operate (governance continua).
✅ Costruzione: quantificare costo reale, beneficio atteso, metro di misura, e la ragione per cui l’approccio tradizionale non basta. Esercizio: monitorare i costi per caso d’uso; ottimizzare token, chiamate ai modelli, infrastruttura. Pratiche FinOps dal primo giorno.
❌ Non trattare i costi dell’AI come “spese tecniche” al di fuori del bilancio. Non dare per acquisito il vantaggio economico: dimostrarlo caso per caso.
9. Dove collocare l’intelligenza
La scelta di dove collocare il modello e i dati va effettuata esplicitamente. Tipicamente, modelli di frontiera in cloud per compiti generici; modelli più piccoli e specializzati, in sede (on-premise) o edge, per dati sensibili o per esigenze di latenza. Architetture ibride (es. RAG con dati in loco e modello in cloud) quando conviene.
✅ Scegliere l’architettura in base a due criteri: la sensibilità dei dati (GDPR, NIS2, vincoli di settore); il profilo di utilizzo effettivo.
❌ Non adottare posizioni di principio del tipo “tutto in cloud” o “tutto in casa”. Il criterio è tecnico ed economico, non una preferenza ideologica.
Si parte dal problema, non dal modello
I nove punti non risolvono il problema di adozione. Servono per arrivare alla decisione con il minor numero possibile di assunzioni implicite. Se, dopo averli esaminati tutti, resta incertezza, è un buon segnale: significa che il problema è stato preso sul serio. Se si saltano tutti, i rischi di insuccesso aumentano.
Proprio in questi giorni, ho ricevuto una mail con The Management Tip of the Day di Harvard Business Review, distillata dall'articolo di David De Cremer “When Developing an AI Strategy, Beware the Urgency Trap”, che dice:
If your AI initiatives aren’t delivering meaningful results, the problem may not be the technology, but the way you’re approaching it. Instead of chasing short-term efficiency, use AI to strengthen your organization’s long-term strategy.
Start with purpose. Before choosing tools, define the value you want to create. Ask yourself which problems matter most to your mission, where people add unique value, and how AI can support that work instead of simply accelerating existing processes.
Resist the urgency trap. Don’t let pressure to move quickly dictate your AI strategy. Fast deployments often overlook the skills, processes, and cultural changes needed for lasting success. Give people time to learn, adapt, and build trust in new ways of working.
Use AI to advance your vision. Treat AI as part of a broader transformation, not an isolated productivity tool. Align initiatives across teams so they help employees make better decisions, collaborate more effectively, and create greater value over time.
Dice le stesse cose con parole diverse. Segno che sono osservazioni di buon senso, maturate nella pratica. Temi su cui vale la pena riflettere e lavorare.
Questo post è stato scritto con l’assistenza di Claude. Le idee, le posizioni e il ragionamento sono miei.
© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it