Progettare una soluzione di AI locale non significa scegliere prima una GPU. Significa capire quale problema risolvere, quali dati proteggere, quanti utenti servire e quale livello di qualità e velocità sia realmente necessario.
Un modello eseguito su un PC, una workstation o un server può offrire controllo, continuità e costi prevedibili. Può anche diventare lento, insicuro o inutilizzabile se hardware, rete, accessi e verifiche non sono stati progettati insieme.
Indice
- Quando l’AI locale ha senso
- La checklist in otto decisioni
- Tre architetture semplici
- Come dimensionare RAM, VRAM e contesto
- RAG e documenti aziendali
- Sicurezza, rete e continuità
- Collaudo e criteri di accettazione
- Errori frequenti e FAQ
Che cosa significa davvero AI locale
Con AI locale intendiamo l’esecuzione di modelli e componenti nell’infrastruttura controllata dall’utente o dall’organizzazione: un computer personale, una workstation, un mini PC oppure un server interno. Non significa necessariamente assenza di Internet: aggiornamenti, download dei modelli, telemetria o integrazioni possono comunque collegarsi a servizi esterni.
Per questo la prima verifica non è “gira in locale?”, ma:
- dove vengono elaborati prompt, file e output?
- quali componenti comunicano con l’esterno?
- chi può accedere al sistema e ai log?
- come vengono aggiornati modelli, container e dipendenze?
Quando conviene e quando no
L’AI locale è interessante quando privacy, latenza, continuità offline, personalizzazione o volume rendono utile mantenere il controllo dell’infrastruttura. Può essere meno conveniente quando servono modelli molto grandi, capacità multimodali avanzate, picchi imprevedibili o un servizio gestito senza competenze sistemistiche interne.
| Esigenza | Locale può aiutare | Verifica necessaria |
|---|---|---|
| Dati sensibili | Elaborazione nell’infrastruttura controllata | Accessi, log, backup e traffico esterno |
| Uso offline | Continuità senza API cloud | Dipendenze, licenze e aggiornamenti |
| Costi ricorrenti | Hardware ammortizzabile | Energia, gestione e capacità reale |
| Qualità massima | Modelli specializzati e RAG | Confronto con alternative cloud |
| Molti utenti | Server condiviso | Concorrenza, code e SLA |
La checklist in otto decisioni
1. Definisci caso d’uso, utenti e risultato
“Vogliamo un chatbot interno” non è ancora un requisito. Specifica attività, destinatari e output: riassumere procedure, rispondere su manuali, classificare ticket, preparare bozze oppure assistere lo sviluppo software.
Per ogni caso annota:
- numero di utenti totali e contemporanei;
- lunghezza media di prompt e documenti;
- tempo di risposta accettabile;
- lingue e formati richiesti;
- azioni consentite e approvazioni obbligatorie.
Un assistente personale e un servizio per venti colleghi non hanno lo stesso dimensionamento. La concorrenza moltiplica memoria, contesto e carico.
2. Classifica dati e vincoli
Separa dati pubblici, interni, riservati, personali e regolamentati. Definisci chi può consultarli, per quanto tempo conservarli e dove possono essere copiati. La collocazione locale riduce alcuni trasferimenti, ma non protegge automaticamente da account condivisi, cartelle aperte, backup non cifrati o log troppo dettagliati.
Prima della prova usa dati sintetici o anonimizzati. La guida su come usare l’AI in sicurezza contiene i controlli minimi.
3. Prepara un set di prova realistico
Raccogli da 20 a 50 richieste rappresentative, comprese quelle difficili: documenti incompleti, domande ambigue, termini aziendali, prompt ostili e casi nei quali il sistema deve dichiarare di non sapere.
Per ogni richiesta definisci in anticipo:
- elementi obbligatori nella risposta;
- errori inaccettabili;
- fonte attesa;
- tempo massimo;
- persona che valuta il risultato.
Senza un set fisso è facile preferire il modello che ha prodotto una risposta brillante una sola volta.
4. Scegli modello, licenza e runtime
Non tutti i modelli distribuiti come pesi scaricabili sono “open source” nello stesso senso. Controlla model card, licenza, usi consentiti, limiti, lingue, dimensione e quantizzazione. Hugging Face raccomanda di consultare licenza, usi previsti, limitazioni, dati ed evaluation presenti nella model card.
Per iniziare puoi usare Ollama oppure LM Studio. Il runtime non migliora da solo il modello: gestisce download, caricamento, API e uso dell’hardware. Per un’interfaccia multiutente puoi valutare Open WebUI collegato a Ollama.
5. Stabilisci contesto, RAG e strumenti
La context window è la quantità massima di token che il modello può considerare durante una richiesta. Aumentarla consuma più memoria; Ollama documenta inoltre che richieste parallele possono moltiplicare l’allocazione del contesto. Non impostare quindi il valore massimo “per sicurezza”.
Per molti documenti è preferibile un sistema RAG, che recupera i passaggi pertinenti prima della risposta. Il RAG non elimina gli errori: bisogna valutare estrazione, chunk, embedding, ricerca, permessi e citazioni.
6. Dimensiona RAM, VRAM, storage e concorrenza
Il requisito non dipende soltanto dal numero di parametri. Pesano quantizzazione, lunghezza del contesto, batch, richieste parallele, modelli caricati e uso di embedding o reranker.
Segui questo ordine:
- scegli uno o due modelli candidati;
- misura memoria e velocità sul carico reale;
- aumenta il contesto soltanto se i test lo richiedono;
- prova il numero atteso di utenti contemporanei;
- aggiungi margine per sistema operativo, interfaccia e database.
Una GPU accelera l’inferenza quando modello e configurazione sono supportati. Verifica la compatibilità corrente nella documentazione del runtime: driver, backend NVIDIA, AMD, Apple Metal e Vulkan cambiano nel tempo. Se una parte del modello viene trasferita alla CPU, le risposte possono rallentare sensibilmente.
7. Progetta accessi, rete e continuità
Un servizio raggiungibile da altri dispositivi deve essere trattato come un’applicazione aziendale. Prevedi:
- account individuali e ruoli;
- registrazione disabilitata o soggetta ad approvazione;
- HTTPS, reverse proxy e cookie sicuri;
- VPN, segmentazione o allowlist quando opportuno;
- rate limiting e timeout coerenti con l’inferenza;
- backup verificati e procedura di ripristino;
- aggiornamenti controllati e rollback.
Open WebUI raccomanda per ambienti sensibili VPN, proxy zero-trust o reverse proxy con autenticazione e protezioni contro abusi. Se usi Docker, non esporre il socket del demone senza SSH o TLS: chi lo controlla può ottenere privilegi elevati sull’host.
8. Misura, documenta e approva
Registra modello, digest o versione, quantizzazione, prompt di sistema, parametri, contesto, runtime e hardware. Ripeti il set di test dopo ogni modifica significativa.
Le metriche minime sono:
- qualità e completezza della risposta;
- precisione delle citazioni;
- tempo al primo token e tempo totale;
- token o richieste al minuto;
- RAM, VRAM, CPU/GPU ed energia;
- errori, code, timeout e correzioni umane.
Il NIST AI RMF per l’AI generativa suggerisce di integrare affidabilità e gestione del rischio lungo l’intero ciclo di vita, non soltanto al momento della scelta del modello.
Tre architetture semplici
Scenario A: un solo utente
PC o Mac, runtime locale e interfaccia desktop. È adatto a scrittura, analisi di file non critici e sperimentazione. Mantieni cifratura del disco, account protetto e backup. È il modo più semplice per verificare se il caso d’uso produce valore prima di acquistare altro hardware.
Scenario B: piccolo gruppo interno
Workstation o server con Ollama, interfaccia web, account individuali e accesso tramite LAN protetta o VPN. Occorre testare utenti simultanei, code e permessi sui documenti. Non pubblicare direttamente le porte del runtime su Internet.
Scenario C: assistente documentale aziendale
Server di inferenza, interfaccia autenticata, pipeline RAG, archivio documentale governato, logging, monitoraggio e backup. I permessi devono essere applicati prima del recupero: il modello non deve ricevere un passaggio che l’utente non è autorizzato a leggere.
Esempio di capitolato minimo
Caso d’uso: rispondere alle domande degli operatori usando procedure approvate.
Utenti: 15 totali, 4 simultanei.
Dati: documenti interni, senza dati sanitari o credenziali.
Risultato: risposta in italiano con citazione del documento e della sezione.
Prestazioni: prima risposta entro 5 secondi e completamento entro 25 secondi nel 95% dei test.
Qualità: almeno 90% delle risposte campione contiene la fonte corretta; in assenza di evidenze il sistema dichiara di non poter rispondere.
Sicurezza: account individuali, accesso tramite VPN, HTTPS, backup giornaliero e log senza contenuto sensibile.
Continuità: ripristino documentato, aggiornamenti in finestra e rollback della versione precedente.
Numeri e soglie vanno adattati, ma questo formato rende confrontabili hardware, modelli e proposte dei fornitori.
Collaudo prima della produzione
- installa la soluzione in un ambiente isolato;
- carica soltanto dati autorizzati e rappresentativi;
- esegui il set di test e conserva i risultati;
- simula utenti contemporanei e indisponibilità;
- verifica backup, ripristino e aggiornamento;
- esegui una revisione di rete e permessi;
- avvia un pilota con pochi utenti;
- approva la produzione soltanto con criteri soddisfatti.
Errori frequenti
Acquistare hardware prima di avere un test
Il modello più grande che entra nella VRAM potrebbe non essere quello più adatto. Prima misura un candidato sul compito reale.
Usare benchmark generici come unica prova
I benchmark non rappresentano terminologia, documenti e rischi dell’organizzazione. Affiancali a esempi interni valutati da persone competenti.
Confondere accesso locale e isolamento
Un’applicazione in LAN può avere registrazione aperta, password deboli o cartelle condivise. Verifica sempre il percorso completo dei dati.
Dimenticare licenze e aggiornamenti
Modello, interfaccia, database e container hanno condizioni e vulnerabilità differenti. Crea un inventario con proprietario e ciclo di aggiornamento.
Ignorare il carico simultaneo
Una demo con un utente non dimostra che il sistema regga un team. Riproduci il numero realistico di conversazioni e documenti.
FAQ
Serve sempre una GPU?
No. Modelli piccoli possono funzionare su CPU o memoria unificata, ma la velocità potrebbe non essere sufficiente. La GPU diventa importante per modelli più grandi, contesti estesi e più utenti.
Quanta VRAM serve?
Non esiste un valore universale. Dipende da modello, quantizzazione, contesto e concorrenza. Misura il modello scelto e aggiungi margine; non affidarti soltanto alla dimensione del file.
Locale significa conforme al GDPR?
No. La collocazione è un elemento dell’architettura, non una conformità automatica. Servono finalità, base giuridica, minimizzazione, sicurezza, conservazione e gestione dei diritti applicabili.
Posso collegare documenti aziendali?
Sì, con una pipeline RAG o con il contesto diretto, ma devi governare versioni, permessi, estrazione e citazioni. Evita un’unica base conoscenza accessibile indistintamente a tutti.
Ollama e Open WebUI sono la stessa cosa?
No. Ollama gestisce modelli e API; Open WebUI fornisce un’interfaccia, utenti e funzioni aggiuntive. Possono essere installati sulla stessa macchina o separati.
Conclusioni
Una buona soluzione di AI locale nasce in quest’ordine: problema, dati, test, modello, hardware, sicurezza e gestione. Invertire l’ordine porta spesso a una workstation costosa che esegue una demo, ma non un servizio affidabile.
Parti da un pilota limitato, confronta locale e cloud con gli stessi esempi e dimensiona soltanto ciò che hai misurato. Il vero vantaggio del locale è il controllo; quel controllo richiede progettazione e responsabilità.
Fonti principali
- Ollama: context length e memoria
- Ollama: compatibilità hardware e GPU
- Open WebUI: hardening della distribuzione
- Docker: proteggere l’accesso al daemon
- Hugging Face: model card e licenze
- NIST: profilo AI RMF per l’AI generativa
Articoli correlati
- Open WebUI con Ollama: installazione e sicurezza
- Modelli open source e open weights
- RAG: collegare l’AI ai propri documenti
- Ollama: che cos’è e come funziona
Iscriviti gratuitamente alla newsletter di Basi di AI per ricevere guide pratiche, checklist e aggiornamenti selezionati.
