Negli ultimi diciotto mesi la domanda più frequente dei clienti enterprise è cambiata di segno. Non è più «possiamo usare l'IA generativa?», ma una versione molto più specifica: «possiamo elaborare questi documenti senza che escano dal nostro perimetro?».
È una domanda legittima e oggi ha una risposta tecnicamente solida per una parte significativa dei casi d'uso. L'hanno resa possibile tre fattori insieme: modelli compatti finalmente utili, un tooling maturato al punto da essere gestibile da un team IT ordinario, e una pressione normativa crescente (GDPR, AI Act, NIS2, requisiti settoriali su sanità e finanza) che rende il confine del dato un tema di governance, non di preferenza tecnica. Questo articolo prova a distinguere il segnale dal rumore.
Distillazione e quantizzazione, senza mitologia
L'accessibilità dei modelli locali poggia su due tecniche distinte, spesso confuse. La distillazione addestra un modello «studente» compatto a riprodurre il comportamento di un modello «insegnante» molto più grande: non è una compressione senza perdite, è un trasferimento selettivo di competenza. Il risultato si comporta molto meglio di quanto la dimensione suggerirebbe — ma resta un modello da 3–8 miliardi di parametri. La quantizzazione riduce invece la precisione numerica dei pesi, tipicamente da 16 a 4–5 bit (formati come GGUF): l'occupazione di memoria cala di circa quattro volte, con una perdita marginale nella maggior parte dei task applicativi.
Il punto che raramente viene detto è che il degrado non è uniforme. I task ristretti e verificabili — estrazione di entità, classificazione, riassunto estrattivo, normalizzazione di dati — reggono molto bene; il ragionamento lungo multi-passaggio e l'analisi su contesti molto ampi degradano in modo netto. La conseguenza progettuale è semplice: si progetta per il task, non per il benchmark. Un modello da 7B che risolve bene tre casi d'uso definiti vale più di un generalista che ne risolve venti in modo mediocre.
Lo stack minimo, e cosa manca quasi sempre
Il runtime. Ollama si è imposto come standard di fatto per l'esecuzione locale: gestisce download, versioni ed esposizione dei modelli via API, con un'esperienza che ricorda Docker: eccellente per il singolo utente e per i pilota; per scenari server multi-utente conviene valutare fin da subito runtime orientati al throughput come vLLM, perché in produzione il collo di bottiglia non è la memoria ma le richieste concorrenti.
Il contesto. Un modello locale, da solo, non conosce l'azienda: serve un livello di retrieval che indicizzi documenti, wiki e ticket e passi al modello i frammenti pertinenti. Implementazioni leggere come LightRAG rendono questo strato accessibile senza infrastruttura pesante. E vale la pena essere espliciti: in gran parte dei progetti documentali la qualità dipende più dal retrieval che dal modello — ne abbiamo scritto in dettaglio, ed è la stessa lezione che ci ha insegnato la nostra piattaforma, costruita proprio su questi componenti: Ollama, vLLM, LightRAG.
L'adattamento. Strumenti come Unsloth hanno reso il fine-tuning con tecniche LoRA/QLoRA praticabile su hardware modesto. Il consiglio operativo, però, è considerarlo la terza opzione, non la prima: prima il prompt, poi il retrieval, e solo se entrambi falliscono in modo misurabile si introduce un artefatto da versionare e rimettere alla prova a ogni cambio di modello base.
Quello che manca nei tutorial. Tra un proof of concept e un sistema aziendale c'è uno strato che nelle guide non compare: identità e permessi (l'indice deve rispettare i permessi dell'utente), logging, valutazione continua della qualità, processo di aggiornamento dei modelli. È qui che si concentra la maggior parte del costo reale.
Tre scenari in cui il locale funziona davvero
1 · Pre-triage documentale su dati riservati. Contratti, fascicoli HR, documentazione clinica, pratiche assicurative. Il modello non decide: estrae, classifica, evidenzia clausole anomale e prepara il lavoro a un revisore umano. Il valore è nel tempo di lettura risparmiato; il rischio è contenuto perché l'output è sempre verificato.
2 · Ricerca semantica sul patrimonio interno. Verbali, documentazione tecnica, storico ticket: recupero in linguaggio naturale su archivi che nessuno riesce più a navigare per cartelle. Anche qui il grosso lo fa il retrieval; il modello sintetizza.
3 · Assistenza allo sviluppo in ambienti isolati. Difesa, infrastrutture critiche, ambienti certificati: il codice proprietario non lascia il repository e spesso la rete verso l'esterno semplicemente non esiste. Qui il locale non è un'ottimizzazione — è l'unica opzione.
Si aggiunge un quarto scenario in crescita: l'operatività su edge — cantieri, impianti, siti remoti — dove la connettività è intermittente e l'affidabilità conta più della qualità marginale della risposta.
Dove il locale non conviene
L'onestà su questo punto distingue una valutazione tecnica da una campagna di marketing. Il ragionamento esteso — analisi comparative complesse, sintesi su decine di documenti eterogenei, testo di qualità editoriale — resta territorio dei modelli frontier, e il divario non si colma con la quantizzazione. I carichi multi-utente non dimensionati: un modello che risponde in due secondi sul laptop può impiegarne venti con dieci richieste concorrenti; si dimensiona sul throughput, non sulla memoria. E il costo totale nascosto: un modello locale non aggiornato è debito tecnico — servono rivalutazioni periodiche, test di regressione e qualcuno che se ne occupi. Sotto una certa soglia di volume, l'API resta largamente più economica della gestione interna.
Dimensionare l'hardware: regole pratiche
- Regola empirica: per un modello quantizzato a 4 bit, i GB di memoria necessari sono circa i miliardi di parametri × 0,6 — più lo spazio per la finestra di contesto.
- Apple Silicon: la memoria unificata aiuta — con 16 GB si gestiscono modelli 7–8B, con 32–64 GB si sale a 14–32B.
- GPU dedicata: 8–12 GB di VRAM coprono bene la fascia 7–8B a velocità interattiva.
- Solo CPU: adatta alle elaborazioni batch notturne, molto meno all'interazione sincrona.
- Server condiviso: una GPU da 24–48 GB serve una decina di utenti concorrenti su modelli 7–8B. Oltre le venti persone è quasi sempre più efficiente — anche gestionalmente — dell'installazione su ogni endpoint.
Tre domande per decidere (e l'architettura che ne esce)
Tre domande, in quest'ordine: il dato può uscire dal perimetro? (domanda organizzativa prima che tecnica); il task è ristretto e verificabile? (se non si sa dire cosa sia una risposta corretta, nessuna infrastruttura salverà il progetto); il volume giustifica l'infrastruttura? (sotto certe soglie l'API è la scelta razionale).
Nella maggior parte dei casi la risposta non è binaria, e l'architettura più sensata è ibrida: un livello di routing che indirizza le richieste sui dati riservati verso il modello locale — nel perimetro dedicato — e tutto il resto verso il cloud, con policy esplicite e tracciabili. La sovranità sul dato diventa una proprietà del sistema, non una rinuncia funzionale.
Un percorso di adozione in 90 giorni
Settimane 1–3 · Perimetro. Classificazione dei dati e selezione di due casi d'uso reali, ciascuno con un referente di business. Settimane 4–8 · Prova sul campo. Prototipo funzionante e, soprattutto, un set di valutazione: 30–50 casi reali con la risposta attesa — l'investimento più sottovalutato, quello che distingue una misura di successo da un'impressione. Settimane 9–12 · Pilota. Rilascio a 10–20 utenti, metriche, decisione documentata: estendere, correggere o fermarsi.
In sintesi
L'IA locale non sostituisce il cloud e non è una risposta universale. Risolve in modo elegante una classe di problemi ben definita: il dato non può muoversi, il task è circoscritto, la verificabilità conta più della brillantezza. Per quella classe — che nelle organizzazioni regolamentate è tutt'altro che marginale — la tecnologia è matura, gira su hardware spesso già in azienda e si valuta in un trimestre con un investimento contenuto. Il resto, come sempre, è una questione di architettura: se volete impostarla con un minimo di serietà, parliamone.
