In breve
L’IA generativa (quella di ChatGPT, Copilot e simili) può funzionare anche in casa, su un computer dedicato in azienda, senza mandare i dati su servizi cloud esterni. Bastano un mini-PC pensato per l’IA da circa 1.500-2.000 euro e dei programmi gratuiti (Ubuntu Server, Ollama, n8n). Noi l’abbiamo costruito così. Funziona bene per automatizzare lavori ripetitivi piccoli (centinaia di operazioni al giorno), come classificare e-mail o leggere documenti. Non funziona bene se deve servire decine di persone in chat contemporaneamente o se servono modelli IA molto grandi. Il vantaggio è che i dati dei clienti restano in casa: si elimina alla fonte il problema del trasferimento a un fornitore IA esterno, senza doverlo gestire con un DPA contrattuale. Lo raccontiamo qui senza pretese: ecco cosa abbiamo imparato e dove abbiamo inciampato.
I servizi IA sui cloud sono potenti, ma con due problemi: costi ricorrenti e quote di token (l’unità con cui si misura l’uso) che, finite, ti lasciano a piedi; e GDPR, perché i dati dei clienti escono dall’azienda.
Da qui due domande:
- Qual è l’hardware minimo per far girare un modello IA in casa su piccoli carichi ripetitivi?
- Quali sono questi carichi, in pratica?
Per noi, oggi, funziona; magari qualche informazione può essere utile anche a te.
La scelta dell’hardware
Non avevamo bisogno di addestrare modelli da zero. Volevamo eseguirli, in casa, con tempi accettabili sui nostri volumi: centinaia di chiamate al giorno, non centinaia di migliaia.
La scelta è caduta su un Minisforum AI X1 Pro: AMD Ryzen AI 9 HX 470 (12 core, 24 thread), Radeon 890M integrata, 32GB DDR5, SSD da 1TB.
Il punto interessante per i modelli LLM è la RAM unificata: la GPU integrata non ha una sua memoria separata, “vede” la RAM del sistema. Abbiamo allocato 16GB alla GPU, 16GB al sistema operativo. Una RTX 3060 da 12GB, in confronto, costa di più, scalda di più, e offre 4GB di VRAM in meno dei 16GB che abbiamo allocato qui.
Non è una scelta universale. Per servire 50 utenti contemporanei o girare modelli da 70B parametri, questa macchina non basta. Per noi (automazioni interne, volumi dimensionati su un piccolo team) era esattamente il punto in cui hardware e capacità si incontravano senza forzature.
Costo: intorno ai 1.500-2.000 euro. Nessun ammortamento eterno, nessun contratto cloud che cresce ogni mese.
Lo stack che gira
Sull’hardware ci abbiamo messo Ubuntu Server (niente desktop, niente fronzoli). Sopra Ubuntu, tre componenti core:
Ollama come motore di esecuzione dei modelli. È un progetto open-source che semplifica radicalmente l’installazione e la gestione dei modelli LLM locali. Lo abbiamo configurato per usare il backend Vulkan (la GPU integrata Radeon 890M non è supportata bene da ROCm, ma Vulkan funziona) e per tenere i modelli sempre in memoria, così la prima richiesta non aspetta il caricamento.
I modelli che effettivamente usiamo:
- qwen3:8b: generalista, supporta function calling, ~5GB di VRAM. È quello che fa la maggior parte del lavoro: classificazione testi, generazione di brevi risposte, estrazione di campi strutturati.
- minicpm-v: multimodale (testo + immagini), ~5GB di VRAM. Lo usiamo per leggere documenti scansionati, un caso d’uso sorprendentemente difficile per i modelli generici.
Entrambi stanno in VRAM contemporaneamente (10-11GB su 16 disponibili), così possiamo passare da un task all’altro senza ricaricare.
Open WebUI come interfaccia web di chat. Sulla carta permette di usare il modello locale dal browser, rendendo l’esperienza visivamente uguale a ChatGPT, con conversazioni separate, ricerca web integrata, caricamento di documenti. In pratica abbiamo trovato dei limiti significativi che racconto nella sezione successiva.
n8n come orchestratore di workflow. È il pezzo che fa girare le automazioni: cattura eventi (un’e-mail in arrivo, un PDF caricato, un trigger schedulato), chiama l’LLM via API, smista il risultato verso il gestionale o un altro sistema. Open-source, self-hosted. Quando parliamo di “task automatizzati”, la cosa che li orchestra è n8n.
Tempi di risposta reali: ~6 token al secondo. Per chi non mastica il numero: una risposta articolata di 200-300 parole arriva in 30-60 secondi. Non è un assistente in tempo reale, ma per task asincroni (classificare un’e-mail, estrarre dati da un documento) è più che accettabile.
Tutto questo gira su un singolo dispositivo dedicato, sempre acceso.
Quello che NON va
Sarebbe disonesto dire che funziona tutto. Il problema dominante, dichiariamolo subito, è la velocità della RAM.
La GPU integrata non ha memoria dedicata: “vede” la RAM DDR5 del sistema, condivisa col resto del PC. La banda è inferiore a una VRAM GDDR6/HBM dedicata, e la banda è esattamente il fattore che determina i token/secondo in un LLM. Il nostro tetto è ~6 token/sec; una GPU dedicata farebbe 3-5x meglio.
Da qui derivano tre conseguenze pratiche:
1. Modelli sopra i 9B parametri sono fuori scala. Qwen 14B, Llama 13B generano a 1-2 token/sec, inutilizzabili. Restiamo nei 7-8B.
2. Open WebUI è troppo lento, in pratica inutilizzabile. I 6 token/sec significano 30-60 secondi per una risposta articolata: in chat live l’attesa è frustrante. Con un secondo utente collegato il sistema collassa, sembra piantato. Per chat condivisa, non è la strada. Per task automatizzati via API (workflow, integrazioni con n8n), invece, il batching asincrono lavora bene su questo hardware.
3. La chat interattiva è lenta. Per task asincroni (classificare, estrarre) i 6 token/sec non si notano. Per chiacchiera live, è lentino.
Un quarto limite scollegato dalla RAM: Qwen 3.5 con backend Vulkan crasha, bug noto del runtime. Per ora usiamo Qwen 3 (versione precedente), che funziona bene.
Per chi cerca uno strumento da 50 utenti contemporanei, non è la risposta. Per chi vuole automatizzare flussi interni con dati che non escono, sì.
Cosa ci stiamo facendo
Tornando alla domanda 2 dell’introduzione: quali carichi di lavoro valeva la pena automatizzare? Tre, finora.
1. Classificazione errori prodotto (in produzione da settimane). Una casella di posta riceve gli errori automatici dei nostri software. Ogni 10 minuti il sistema controlla, l’LLM legge l’e-mail e la classifica; per gli errori risolvibili dal cliente (es. “campo destinatario vuoto”), invia automaticamente al cliente una e-mail con istruzioni. I casi che il modello non riconosce restano nella coda umana. Risultato: meno tempo del tecnico passato a rispondere a errori ricorrenti che il cliente sistema da solo.
2. Classificazione e-mail backoffice (in produzione). Le e-mail amministrative in arrivo passano da un classificatore: ripulite dall’HTML, taggate per tipo, notificate al team via Adaptive Card su Teams. Riduce il “filtro mentale” che ogni mattina si fa per smistare la posta.
3. Estrazione dati da PDF di attestati formazione (in sviluppo). Per MIRMI, il nostro gestionale per RSPP/sicurezza, gli studi clienti gestiscono ~200 attestati l’anno, inseriti a mano. Stiamo testando il caricamento massivo: il PDF arriva, il modello multimodale legge nome/cognome/CF/data/titolo del corso, prepara un record strutturato, l’utente valida prima della scrittura. Ne parliamo a parte in un articolo dedicato.
Tutti e tre stesso pattern: task ripetitivo + dato strutturato in uscita + validazione umana quando serve. Niente che richieda intelligenza generale: precisione su compito specifico.
Perché lo raccontiamo
Non è un manuale. Lo raccontiamo perché diversi nostri clienti ci stanno chiedendo informazioni sull’IA: cosa usare, dove finiscono i dati, se conviene un setup proprio. Le risposte che diamo a voce le abbiamo messe in altri articoli qui sul lab:
- GDPR e servizi IA blasonati: perché ChatGPT, Copilot e gli altri pongono domande di trattamento dati da chiarire prima di firmare.
- n8n + PDF → dati nel gestionale: come il pattern di estrazione strutturata (punto 3 qui sopra) gira in produzione.
- n8n + e-mail aziendali: come si automatizza la classificazione e-mail con un LLM in casa.
Progetto terminato con successo, competenze acquisite, soluzioni in produzione. Se queste informazioni ti risulteranno utili, avremo fatto bingo.
Domande frequenti
Quanto costa costruire un server IA in azienda per uso interno?
Per un setup dimensionato su un piccolo team (centinaia di chiamate al giorno) basta un mini-PC pensato per l’IA: indicativamente 1.500-2.000 euro per l’hardware. I software (Ubuntu Server, Ollama, Open WebUI, n8n) sono gratuiti e open-source.
Quali modelli IA si possono far girare in locale su hardware piccolo?
Su un mini-PC con APU AMD recente e 32GB di RAM si possono eseguire modelli LLM da 7-9 miliardi di parametri (es. qwen3:8b, modelli multimodali da ~5GB di VRAM). Modelli oltre i 9B richiedono hardware più potente.
Un server IA in casa è conforme al GDPR?
L’on-prem elimina il trasferimento dei dati a un fornitore IA esterno: su quel fronte non serve un DPA perché i dati non escono. Non è però una “conformità automatica”: gli altri profili GDPR (base giuridica del trattamento interno, eventuale DPIA se il trattamento lo richiede per volumi o categorie di dati) restano da valutare come per qualunque trattamento aziendale. Il self-host chiude un capitolo importante, non l’intera materia.
Per quanti utenti contemporanei è dimensionato un server IA su mini-PC?
Praticamente single-user per chat interattiva. Il limite della RAM condivisa con la GPU integrata (~6 token/secondo) rende l’esperienza di chat condivisa molto lenta. Per task asincroni (workflow, classificazione, estrazione) il pattern lavora bene anche con volumi più alti.
Quali alternative esistono se serve più potenza?
GPU dedicata (es. RTX 4060 Ti, RTX 4090) per modelli più grandi e velocità di inferenza superiore; oppure servizi cloud enterprise (Claude Enterprise, OpenAI Enterprise, Azure OpenAI) con DPA e residency EU per chi non può fare on-prem.
