Quando si parla di "usare l'AI in azienda" spesso si pensa al chatbot. Ma i Large Language Model possono fare molto di più: leggere migliaia di documenti e rispondere con precisione chirurgica, completare task complessi in autonomia, essere addestrati sul vocabolario specifico del tuo settore.
Il problema è che RAG, agenti AI e fine-tuning sono strumenti diversi — con costi, complessità e casi d'uso diversi. Usare il martello quando serve il cacciavite è lo spreco più comune nei progetti AI aziendali.
In questo articolo spieghiamo cosa è cosa, con esempi concreti.
Cos'è un LLM e perché è diverso dai sistemi precedenti
Un Large Language Model è una rete neurale addestrata su enormi volumi di testo che ha sviluppato una capacità di ragionamento linguistico generalista. Non segue regole scritte a mano — "capisce" il testo e genera risposte coerenti con il contesto.
La differenza pratica rispetto ai vecchi sistemi NLP o ai chatbot basati su alberi decisionali è enorme: un LLM gestisce domande mai viste prima, ragiona per analogia, sintetizza informazioni da fonti multiple e produce output strutturato (JSON, HTML, codice) su richiesta.
RAG: quando il modello deve rispondere usando i tuoi dati
Il problema principale di un LLM nudo è che sa solo ciò su cui è stato addestrato — e quella conoscenza si ferma a una data di cutoff. Se gli chiedi informazioni sui tuoi prodotti, le tue policy aziendali o gli ultimi contratti firmati, inventerà.
RAG (Retrieval Augmented Generation) risolve questo problema: prima di rispondere, il sistema cerca nei tuoi documenti i paragrafi rilevanti e li inietta nel contesto. Il modello risponde basandosi su quei dati reali, non su conoscenze generali.
Esempio concreto: uno studio legale ha 10.000 contratti archiviati. Con RAG, i soci possono chiedere in linguaggio naturale "esistono clausole di non concorrenza superiori a 24 mesi nei contratti del settore tecnologico?" e ottenere una risposta in secondi, con citazione del contratto e del paragrafo specifico.
Quando usare RAG:
- Knowledge base aziendale (manuali, procedure, FAQ interne)
- Ricerca su archivi documentali grandi
- Customer support che deve citare fonti verificabili
- Qualsiasi scenario dove le informazioni cambiano frequentemente
Limiti: la qualità dipende dalla qualità dei documenti e dall'architettura del retrieval. Documenti mal formattati o pipeline di chunking approssimative producono risposte inaffidabili.
Agenti AI: quando il modello deve fare, non solo rispondere
Un agente AI è un LLM dotato di strumenti — la capacità di eseguire azioni nel mondo reale: chiamare API, leggere database, inviare email, scrivere file, fare calcoli. La caratteristica distintiva è il loop plan-act-observe: l'agente pianifica i passi, li esegue, osserva i risultati e aggiusta il piano.
Esempio concreto: un'azienda di e-commerce vuole automatizzare la gestione dei resi. Un agente riceve l'email del cliente, legge il numero ordine, verifica nel gestionale se il reso è nei termini, autorizza il rimborso tramite API di pagamento, aggiorna lo stato nel CRM e risponde al cliente — tutto senza intervento umano per i casi standard.
Quando usare gli agenti:
- Task multi-step con logica condizionale
- Processi che richiedono interazione con sistemi esterni (API, database, email)
- Automazioni dove l'ordine dei passi dipende dai risultati intermedi
- Workflow con volume elevato di casi simili ma non identici
Limiti: gli agenti sono potenti ma richiedono guardrail solidi. Un agente mal progettato può prendere azioni irreversibili. Human-in-the-loop e permission boundary sono fondamentali.
Fine-tuning: quando il modello deve parlare come te
Il fine-tuning è l'addestramento aggiuntivo di un modello su un dataset specifico, per adattarlo al tuo dominio, tono e terminologia. Il modello impara pattern che non erano nel training originale.
Esempio concreto: un'azienda farmaceutica vuole che il modello usi sempre la nomenclatura tecnica corretta, rispetti le linee guida regolatorie nella formulazione delle risposte e abbia lo stesso tono formale dei documenti ufficiali. Il prompt engineering da solo non garantisce la consistenza su scala: il fine-tuning sì.
Quando usare il fine-tuning:
- Dominio con terminologia molto specialistica non coperta dai modelli base
- Consistenza di tono e formato in output ad alto volume
- Quando hai dati di training sufficienti (centinaia/migliaia di esempi)
- Riduzione del costo per task semplici e ripetitivi (modello più piccolo + fine-tuning batte modello grande generico)
Quando NON usare il fine-tuning: se le informazioni cambiano spesso (meglio RAG), se non hai dati di training sufficienti, se il problema si risolve con un buon prompt.
Deployment on-premise: quando i dati non possono uscire
Per alcuni settori — sanità, legale, difesa, finanza — inviare dati a un'API cloud è fuori questione. La soluzione è il deployment locale di modelli open-source (LLaMA 3, Mistral, Phi-3) su hardware dedicato. Le prestazioni sono inferiori ai migliori modelli cloud, ma per molti task aziendali la differenza è trascurabile.
Come scegliere l'approccio giusto
La risposta onesta è: dipende dal problema. Le domande da fare sono:
- Il modello deve rispondere su dati specifici aziendali? → RAG
- Deve fare azioni, non solo rispondere? → Agenti
- Deve avere un tono/terminologia molto specifica e consistente? → Fine-tuning
- I dati non possono uscire dall'azienda? → On-premise
- Combinazione di più casi? → Architettura ibrida
Se vuoi capire quale approccio ha senso per il tuo caso, richiedi una call gratuita di discovery: in 30 minuti mappiamo il problema e stimiamo l'effort.
LLM specifici per dominio: cosa significa davvero
Un LLM specifico per dominio non è necessariamente un modello addestrato da zero. Nella maggior parte dei progetti aziendali il risultato migliore nasce dalla combinazione di un modello generalista, istruzioni precise, terminologia controllata e accesso ai documenti tramite RAG. Il fine-tuning entra in gioco quando servono comportamenti o formati molto consistenti su un grande volume di esempi.
Prima di scegliere misuriamo accuratezza richiesta, frequenza di aggiornamento delle informazioni, disponibilità dei dati, vincoli privacy, latenza e costo per operazione. “Più personalizzato” non significa automaticamente “più addestrato”.
Automazione RAG: dal documento al processo operativo
Una automazione RAG può limitarsi a rispondere citando una procedura, oppure diventare il primo passo di un workflow: recupera le fonti, classifica la richiesta, prepara una bozza e inoltra il caso alla persona responsabile. Le azioni irreversibili dovrebbero restare separate e protette da conferme, permessi e log.
Per esempio, un sistema può leggere documentazione tecnica, individuare il prodotto pertinente e preparare una risposta con i riferimenti usati. Solo dopo la revisione umana la risposta viene inviata. Questo approccio riduce il lavoro ripetitivo senza trasformare il modello in un decisore autonomo.
Checklist prima di avviare un progetto LLM
- Definire un’attività precisa e un indicatore misurabile.
- Identificare fonti autorizzate, proprietari dei dati e frequenza di aggiornamento.
- Preparare un set di domande e casi reali per i test.
- Stabilire quando il sistema deve rifiutare, chiedere chiarimenti o coinvolgere una persona.
- Misurare accuratezza, copertura, tempi e costo prima di ampliare il perimetro.
Digitalora sviluppa applicazioni LLM su misura, assistenti AI interni e assistenti AI per ecommerce. Una discovery iniziale serve a capire se il caso richiede davvero RAG, agenti, fine-tuning o una soluzione più semplice.