Hai sentito parlare di «addestrare l’AI sui dati della tua azienda». Forse qualcuno ti ha detto che è la chiave per avere un assistente che conosce davvero i tuoi prodotti, le tue procedure, i tuoi prezzi.
È vero. Ma c’è un dettaglio importante che spesso manca in quella frase: ci sono almeno due modi molto diversi di farlo. Uno è costoso, lento e nella maggior parte dei casi sbagliato per una PMI. L’altro è più accessibile, più sicuro e — nella grande maggioranza dei casi che incontriamo — più che sufficiente.
In questo articolo spiego la differenza in modo concreto, senza tecnicismi inutili. Così puoi fare una domanda sensata al prossimo fornitore che ti propone di «addestrare un modello».
In breve
Per la maggior parte delle PMI, «addestrare l’AI sulla tua azienda» significa costruire una knowledge base strutturata — documentazione, procedure, listini, offerte — e collegare un modello a quella base tramite un’architettura chiamata RAG. Il fine-tuning classico, cioè riaddestrare il modello sui tuoi dati, è costoso, richiede competenze specialistiche e insegna al modello come comportarsi, non cosa sa. Se il problema è che l’AI non conosce i tuoi prezzi o le tue specifiche tecniche, il fine-tuning è lo strumento sbagliato.
Il problema che vedo spesso nelle aziende manifatturiere
Immagina questa scena — e probabilmente non devi neanche immaginare.
Un commerciale riceve una richiesta di offerta. Per rispondere ha bisogno del datasheet del prodotto, della lista prezzi aggiornata, del capitolato di quella commessa specifica e di tre email scambiate sei mesi fa con quel cliente. Li cerca su SharePoint, nella cartella della posta condivisa, sul server locale e nella sua memoria. Ci mette quaranta minuti. Alla fine l’offerta esce, ma non è detto che sia aggiornata all’ultima revisione del listino.
Questo è il processo che perde tempo. E che espone dati: quando le informazioni sono distribuite tra email personali, cartelle non presidiate e documenti senza controllo versione, la governance è di fatto assente.
L’AI può risolvere questo problema. Ma come lo risolve dipende dall’architettura che scegli. E la scelta sbagliata costa molto e non risolve niente.
Cosa significa davvero «fine-tuning»
Il fine-tuning è il processo con cui prendi un modello AI già addestrato — GPT-4o di OpenAI, Mistral Large, Gemini di Google, o una variante open source come LLaMA di Meta — e lo riaddestri su un insieme di esempi specifici. Gli mostri coppie input/output: «quando ti chiedono questo, rispondi così». Il modello aggiorna i propri parametri interni per comportarsi in modo coerente con quegli esempi.
Cosa ottieni? Un modello che adotta un certo stile, un certo formato, una certa voce. Che smette di fare un errore che ripeteva sistematicamente. Che eccelle su un task molto preciso e stabile nel tempo.
Cosa non ottieni? Un modello che «sa» i tuoi prezzi di oggi. Che conosce la revisione 4 del capitolato che hai caricato ieri. Che ti dice dove trovare la procedura di qualità aggiornata la settimana scorsa.
Come scrive Metacto nella loro decision guide del 2026: «Fine-tuning teaches behavior, not facts. If you want the model to know your pricing page, retrieve the pricing page.»
E Field Journal lo sintetizza ancora meglio: «If the problem is ‘the model keeps being wrong because it does not see the right facts,’ fine-tuning is the wrong tool.»
Il fine-tuning insegna comportamenti. Non trasferisce conoscenza aggiornata. Vale per qualsiasi modello tu stia considerando, indipendentemente dal fornitore.
Cosa significa invece costruire una knowledge base (RAG)
RAG sta per Retrieval Augmented Generation. Il nome è tecnico, il concetto no.
Funziona così: invece di incorporare la conoscenza aziendale nei parametri del modello, la tieni separata in un repository strutturato — PDF, database, email, documenti tecnici, procedure. Quando qualcuno fa una domanda, il sistema cerca prima nei tuoi documenti i pezzi di testo più pertinenti, li passa al modello insieme alla domanda, e il modello genera una risposta basata su quelle fonti.
IBM definisce la RAG come «un’architettura per ottimizzare le prestazioni di un modello AI collegandolo a basi di conoscenza esterne» e sottolinea che «mantiene una divisione tra il modello e quella conoscenza esterna». Questo è il punto cruciale dal punto di vista della sicurezza: i tuoi dati non entrano mai nei pesi del modello. Rimangono nel tuo repository, sotto il tuo controllo, aggiornabili in qualsiasi momento.
I vantaggi pratici per una PMI sono diretti:
- Aggiorni il listino → la knowledge base è aggiornata immediatamente, senza riaddestrare nulla
- Il modello cita la fonte → puoi verificare da dove arriva la risposta
- Puoi revocare l’accesso a certi documenti → il modello smette di rispondere su quell’argomento
- I dati restano nella tua infrastruttura → non alimentano nessun training esterno
Digital360 lo conferma dal punto di vista enterprise: la RAG «permette ai modelli generativi di accedere, in tempo reale, a database proprietari e documentazione interna sicura».
La matrice decisionale: quando usare cosa
Prima di scegliere uno strumento, vale la pena fare la domanda giusta. Field Journal propone un framework semplice: cosa manca?
| Cosa manca | Soluzione |
|---|---|
| Il modello ha i fatti ma risponde male, in formato sbagliato o con voce incoerente | Fine-tuning (leggero, su esempi di output) |
| Il modello non conosce i tuoi dati, i tuoi prezzi, le tue procedure | Knowledge base + RAG |
| Il modello risponde in modo caotico perché le istruzioni sono vaghe | Prompt engineering — ma solo finché il problema è di istruzioni, non di dati mancanti |
| Certi utenti non dovrebbero vedere certi documenti | Controllo degli accessi a livello applicativo |
Sul prompt engineering vale una precisazione: funziona bene quando il modello ha già accesso alle informazioni giuste e il problema è solo come le esprime. Smette di bastare quando mancano i fatti — e allora aggiungere istruzioni più dettagliate nel prompt non cambia nulla, perché il modello non ha comunque i dati da cui attingere.
Abbiamo visto questa confusione costare cara. Un’azienda manifatturiera — componentistica, una sessantina di dipendenti — aveva commissionato un fine-tuning su GPT-4o per fare in modo che il modello «conoscesse i loro prodotti». Il fornitore aveva raccolto centinaia di schede tecniche e le aveva usate come dati di addestramento. Risultato: il modello rispondeva con più scioltezza sul tono, ma continuava a sbagliare i dati tecnici perché quelli corretti erano nella revisione 7 del datasheet, caricata tre settimane dopo la fine del training. Il progetto era costato quattro mesi di lavoro e una cifra significativa. Il problema? Non era mai stato un problema di comportamento. Era un problema di accesso ai dati aggiornati. Una knowledge base RAG avrebbe risolto lo stesso problema in settimane, a una frazione del costo, con la possibilità di aggiornare i documenti in tempo reale.
Il problema reale non è la tecnologia. Sono i dati.
C’è una cosa che emerge da tutte le fonti che ho consultato, e che corrisponde esattamente a quello che vedo nelle aziende con cui lavoriamo.
Metacto lo dice senza giri di parole: «Most stalled AI initiatives we see are not failing because the team picked RAG when they should have fine-tuned. They are failing because the underlying data and context infrastructure can’t reliably feed any technique.»
Tradotto: il progetto AI si blocca non perché hai scelto l’architettura sbagliata. Si blocca perché i tuoi documenti sono distribuiti in quindici posti diversi, senza versioni chiare, con nomi tipo «DEFINITIVO-v3-USARE-QUESTO», scritti da persone diverse in formati incompatibili.
Torniamo al commerciale di prima: quaranta minuti per costruire un’offerta, moltiplicati per cinque offerte a settimana, moltiplicati per dodici settimane in un trimestre. Stiamo parlando di quaranta ore di lavoro qualificato perse in un trimestre — solo per quella persona, solo per quel processo. Non è un problema di AI. È un problema di dati che non si trovano. E nessun modello, né RAG né fine-tuning, funziona bene se i documenti di partenza sono un cantiere.
Prima di scegliere tra fine-tuning e RAG, la domanda da fare è più semplice: i miei documenti sono in ordine abbastanza da permettere a un sistema di trovarli e usarli?
Nella maggior parte delle PMI manifatturiere che incontro — meccanica, componentistica, concia, arredo — la risposta onesta è: parzialmente. E questo è il punto da cui bisogna partire.
Cosa facciamo noi, concretamente
In Fabrika 06 partiamo sempre dal processo e dai dati, prima di scegliere qualsiasi tecnologia. È il modo in cui lavoriamo dal 2009, ed è quello che continua ad avere senso.
Quando valutiamo un progetto AI per un’azienda manifatturiera, la prima cosa che guardiamo non è «quale modello usare». È: quali documenti esistono, dove stanno, chi li aggiorna, chi deve poterli consultare e quali contengono informazioni che non devono uscire dall’azienda.
Da lì costruiamo un perimetro. Poi, quando possibile, partiamo da un caso d’uso circoscritto — un tipo di documento, un processo, un team — con dati a rischio contenuto. Non promettiamo risultati prima di aver visto i dati. E documentiamo test, limiti e risultati in modo che tu possa valutare se continuare.
Per gli aspetti legali — trattamento dei dati, responsabilità, conformità — lavoriamo con professionisti specializzati. Non è il nostro mestiere, e non fingiamo che lo sia.
Se stai valutando un progetto AI per la tua azienda e non sai ancora da dove partire, la cosa più utile che posso offrirti è un’ora di ragionamento insieme sul tuo caso specifico.
Prenota la tua AI Opportunity Sprint gratuita: portami un processo lento e capiamo insieme da dove partire. → AI Opportunity Sprint
Domande frequenti
Cos'è il fine-tuning di un modello AI e quando serve davvero?
Il fine-tuning è il processo con cui si riaddestra un modello su esempi specifici per modificarne il comportamento: il tono, il formato, la coerenza su un task preciso. Serve quando il modello ha già accesso ai fatti giusti ma continua a comportarsi in modo inconsistente. Non serve — ed è lo strumento sbagliato — quando il problema è che il modello non conosce i tuoi dati aziendali aggiornati.
Cos'è una knowledge base e come si collega a un modello AI?
Una knowledge base è un repository strutturato di documenti aziendali: PDF, procedure, listini, email, capitolati. Tramite un'architettura RAG, il modello interroga quella base prima di rispondere, recupera i pezzi di testo pertinenti e genera una risposta ancorata a fonti verificabili. I tuoi dati restano separati dal modello e rimangono sotto il tuo controllo.
I miei dati aziendali entrano nel training del modello se uso la RAG?
No. È una delle differenze fondamentali tra RAG e fine-tuning. Con la RAG, il modello accede ai tuoi documenti al momento della risposta, ma non li incorpora nei propri parametri. Come specifica IBM, la RAG «mantiene una divisione tra il modello e quella conoscenza esterna». Puoi aggiornare o revocare i documenti in qualsiasi momento senza riaddestrare nulla.
Quanto costa costruire una knowledge base per una PMI?
Dipende da quattro fattori: la quantità e la qualità dei documenti esistenti, il livello di strutturazione richiesto, l'architettura scelta e i controlli di accesso necessari. Non esiste un numero fisso. Quello che posso dire è che nella nostra esperienza il costo principale non è tecnologico: è il lavoro di messa in ordine dei documenti, che spesso le aziende sottovalutano.
Cosa succede se i miei documenti sono dispersi e non strutturati?
È la situazione più comune. E — come evidenziano più fonti tecniche — è la causa principale del fallimento dei progetti AI, indipendentemente dall'architettura scelta. Prima di qualsiasi integrazione, vale la pena fare un audit dei documenti esistenti: dove stanno, chi li aggiorna, in che formato, con quale controllo versione. Da lì si capisce cosa è effettivamente pronto per essere usato da un sistema AI.
Un dipendente del marketing potrebbe accedere via AI a documenti riservati dell'HR?
Potrebbe, se la pipeline non è configurata correttamente. Per questo Digital360 sottolinea che «definire chiari permessi di accesso all'interno della pipeline RAG è necessario per evitare che informazioni riservate vengano esposte a utenti non autorizzati». Il controllo degli accessi non è un problema che si risolve nel prompt: è una scelta architetturale che va progettata dall'inizio.
