Paper. What i write

Implementare un Large Language Model locale con strumenti open source su piattaforma Microsoft Windows

Pubblicato il 8 agosto 2026
Vincenzo Calabro' | Implementare un Large Language Model locale con strumenti open source su piattaforma Microsoft Windows

Eseguire un Large Language Model interamente sulla propria workstation Windows non è più un esercizio per appassionati: con Ollama e Open WebUI si mette in piedi in poche ore un assistente AI privato, capace di lavorare offline e sotto pieno controllo. Questa è la sintesi della nostra lecture note tecnica sul tema, con un'attenzione particolare a ciò che conta per chi si occupa di cyber security e digital forensics.

Perché portare l'AI dentro il perimetro

Chi analizza log, evidenze forensi o report di incident response conosce bene il dilemma: gli assistenti AI in cloud sono potenti, ma ogni prompt è un dato che esce dal perimetro. PII contenute nelle evidenze, indicatori di compromissione riservati, dettagli di incidenti non ancora divulgati: materiale che non dovrebbe transitare per infrastrutture di terzi, per quanto contrattualmente tutelate.
Un LLM eseguito in locale ribalta la prospettiva. Prompt, documenti e conversazioni non lasciano mai la postazione, e diventa possibile analizzare artefatti sensibili senza alcuna uscita dal perimetro aziendale. Una volta scaricati i modelli, il sistema opera anche in ambienti air-gapped o in laboratori isolati. Versioni dei modelli, parametri e log restano sotto il controllo dell'organizzazione, a beneficio di riproducibilità e auditabilità. E spariscono rate limit e clausole sul riutilizzo dei dati per finalità di training altrui. Sul fronte GDPR, il trattamento interamente locale favorisce minimizzazione e data residency by design — anche se, come vedremo, gli obblighi sul dato a riposo non svaniscono.

Lo stack: due componenti, zero cloud

La soluzione si regge su due strumenti che si integrano in modo naturale. Ollama è il runtime di inference: basato sul motore llama.cpp, gira come servizio Windows nativo ed espone una REST API su `127.0.0.1:11434`. Gestisce modelli in formato GGUF con pesi quantizzati: la quantization riduce la precisione numerica dei parametri (tipicamente a 4 bit) in cambio di un risparmio di memoria drastico e di una perdita qualitativa contenuta. Regola pratica: un modello in q4_K_M occupa circa 0,6 GB per miliardo di parametri.
Open WebUI è il front-end: un container Docker che offre un'interfaccia conversazionale multi-utente con autenticazione e ruoli, gestione delle knowledge base per il RAG e pannello di amministrazione, raggiungibile via browser su `localhost:3000`. L'intero flusso dei dati resta confinato alla macchina; Internet serve solo per il download iniziale dei modelli.
I requisiti hardware sono più abbordabili di quanto si pensi. Con 16 GB di RAM e nessuna GPU si eseguono modelli da 3–8 miliardi di parametri a velocità adeguate a test e didattica; una GPU da 8 GB di VRAM rende fluido un 8B; con 24 GB di VRAM si arriva a modelli da 27–32B e a un impiego professionale continuativo. Tra le famiglie di interesse: Llama 3.1 (8B) per l'uso generale, Qwen per il multilingua e il coding, Phi-4 per il ragionamento, i distillati di DeepSeek-R1 per i task di reasoning esteso.

Operativi in mezz'ora

Il percorso di installazione è lineare. Ollama si installa dal sito ufficiale o via package manager, dopodiché si scarica un modello e lo si prova da riga di comando:
```powershell
   winget install --id Ollama.Ollama
   ollama pull llama3.1:8b
   ollama run llama3.1:8b --verbose
```
Per Open WebUI serve Docker Desktop con backend WSL2. Un dettaglio del comando di avvio merita attenzione, perché è già una scelta di sicurezza: l'indirizzo esplicito `127.0.0.1` nella pubblicazione della porta evita che l'interfaccia sia raggiungibile da tutta la rete.
```powershell
   docker run -d -p 127.0.0.1:3000:8080 `
      -e OLLAMA_BASE_URL=http://host.docker.internal:11434 `
      -v open-webui:/app/backend/data `
      --name open-webui --restart always `
      ghcr.io/open-webui/open-webui:main
```
Il primo utente registrato diventa automaticamente amministratore; subito dopo conviene disabilitare le registrazioni spontanee e configurare i ruoli.

I vostri documenti, le vostre risposte: il RAG

Il valore vero arriva con la Retrieval-Augmented Generation. I documenti caricati in una knowledge base vengono segmentati in chunk, trasformati in vettori da un embedding model dedicato (ad esempio `nomic-embed-text`) e indicizzati nel vector database integrato. A ogni domanda, i passaggi semanticamente più pertinenti vengono recuperati e forniti al modello, che risponde citando le fonti.
Per un team di sicurezza il caso d'uso è immediato: interrogare in linguaggio naturale security policy, procedure di incident response, standard interni, report di Cyber Threat Intelligence e documentazione post-incident, il tutto rimanendo on-premise e senza alcun riaddestramento del modello. Con un'avvertenza che riprenderemo: i documenti indicizzati entrano nel prompt, quindi vanno sottoposti a vetting prima dell'ingestione.

Un'API per automatizzare il triage

Ollama espone endpoint REST locali (`/api/generate`, `/api/chat`, `/api/embed`) e un endpoint OpenAI-compatible su `/v1`, che consente di riutilizzare librerie e strumenti esistenti semplicemente ridirigendo la base URL verso l'host locale. In pochi minuti si integra il modello in script PowerShell o Python per automatizzare attività ripetitive: pre-classificazione di righe di log, normalizzazione di indicatori di compromissione, sintesi di report, bozze di documentazione. Senza che i dati lascino la postazione.
Il limite va dichiarato con la stessa chiarezza: l'output di un LLM è probabilistico e soggetto ad hallucination. La validazione umana resta obbligatoria, e l'API non va mai collegata ad azioni dispositive — blocchi, cancellazioni, risposte automatiche — prive di revisione.

Il rovescio della medaglia: mettere in sicurezza il deployment

Un LLM locale riduce drasticamente la superficie di attacco legata a terze parti, ma non è intrinsecamente sicuro. Le ricerche condotte con motori come Shodan hanno documentato migliaia di istanze Ollama esposte pubblicamente senza autenticazione, con la possibilità per chiunque di eseguire inference o manipolare i modelli. Il motivo è semplice: l'API di Ollama non implementa autenticazione, e basta un binding sbagliato — o un `-p` di Docker senza indirizzo esplicito — per pubblicare tutto su ogni interfaccia di rete.
Le contromisure essenziali sono poche e verificabili: mantenere il binding su loopback e controllarlo periodicamente con netstat; definire regole firewall inbound esplicite per le porte 11434 e 3000; concedere l'accesso remoto, dove serve davvero, solo attraverso un reverse proxy TLS con autenticazione o una VPN. Sul fronte supply chain, i modelli sono artefatti binari e vanno trattati come software di terze parti: fonti ufficiali, inventario dei digest SHA-256, verifica delle licenze; le estensioni di Open WebUI eseguono codice Python sul server e meritano una code review prima dell'installazione. Restano infine la prompt injection e il RAG poisoning (voce LLM01 della OWASP Top 10 for LLM Applications): un documento ostile caricato in knowledge base può tentare di alterare il comportamento del modello, e la difesa passa dal vetting delle fonti, dalla separazione dei privilegi e dal principio di non considerare mai attendibili le istruzioni provenienti dai dati. A chiudere il cerchio, la protezione del dato a riposo: conversazioni e indici vivono in un volume Docker locale, e BitLocker con backup cifrati non è un optional.

Fine-tuning: quando (non) serve

Per specializzare il modello esiste anche la via del fine-tuning parameter-efficient: con LoRA e QLoRA si addestra circa lo 0,1–1% dei parametri e un modello 7–8B si adatta con 10–12 GB di VRAM in ambiente WSL2, producendo un adapter di pochi megabyte da agganciare in Ollama con una direttiva nel Modelfile. Ma la regola pratica è un'altra: il fine-tuning serve per consolidare stile, formato e tassonomie ricorrenti; per la conoscenza fattuale che cambia nel tempo il RAG resta preferibile, perché si aggiorna all'istante e mantiene tracciabili le fonti. I due approcci sono complementari, non alternativi.

Una nota sulle licenze

Chi guarda alla compliance apprezzerà una precisazione: Ollama è rilasciato con licenza MIT, mentre Open WebUI adotta dalla versione 0.6.6 (aprile 2025) una licenza di derivazione BSD-3 con clausola di protezione del branding, non approvata OSI, con un'esenzione per i deployment fino a 50 utenti. L'uso interno con branding invariato non ne risulta impattato; la rimozione del branding o la redistribuzione richiedono invece una verifica di conformità. E per i modelli vale lo stesso principio: Llama Community License, Apache 2.0 e Gemma Terms non sono equivalenti, e vanno lette rispetto all'impiego previsto.

In conclusione

Uno stack composto da due strumenti gratuiti trasforma una workstation Windows in un ambiente AI completo: chat multi-utente, RAG sui documenti interni, API per l'automazione e, volendo, fine-tuning. Per chi lavora nella sicurezza il beneficio è duplice: si guadagna un assistente che può toccare dati che il cloud non dovrebbe vedere, e si impara sul campo il threat model di una tecnologia che sempre più spesso finirà negli asset da difendere. Un'ultima avvertenza da manuale: l'ecosistema open source degli LLM evolve con estrema rapidità, e comandi, nomi dei modelli e percorsi di menu possono variare tra le versioni — prima di mettere in produzione, verificate i passaggi sull'ultima release degli strumenti.
L'articolo sintetizza la lecture note tecnica "Implementare un Large Language Model locale con strumenti open source su piattaforma Microsoft Windows" (Agosto, 2026), che contiene la procedura completa passo per passo, gli schemi architetturali, la checklist di hardening e la sezione di troubleshooting.
 

Vincenzo Calabro'Vincenzo Calabro' | Ingegnere informatico specializzato in sicurezza informatica e investigazione digitali. Autore di articoli e saggi. Lecturer, Speaker, Trainer.