Ollama in azienda: come costruire un knowledge bot interno on‑prem per PMI

Perché un knowledge bot interno on‑prem con Ollama ha senso per una PMI

Negli ultimi mesi molti CTO e responsabili IT di PMI italiane si sono trovati davanti allo stesso bivio: continuare a sperimentare con SaaS di AI generativa in cloud, oppure portare l’AI in casa, vicino ai dati aziendali.

Per una knowledge base aziendale (procedure, manuali, documentazione tecnica, policy, offerte, contratti) la seconda strada ha spesso più senso: meno rischio di data leakage, più controllo sui costi, integrazione più stretta con i sistemi interni.

Ollama è uno dei mattoncini più interessanti per costruire un knowledge bot interno on‑prem in una PMI: è leggero, gira su hardware standard, supporta diversi LLM open source e si integra bene con stack Python/Node, strumenti di RAG e orchestratori.

In questo articolo vediamo, con un taglio tecnico-pratico:

• quando ha senso usare Ollama per una knowledge base aziendale
• un’architettura di riferimento on‑prem per PMI
• come gestire ingestion, indicizzazione e aggiornamento dei documenti
• pattern di sicurezza, logging e governance
• come stimare costi e risorse e quando ha senso chiedere supporto esterno

Quando scegliere Ollama per la knowledge base aziendale

Prima di parlare di architettura, è utile chiarire il perimetro di utilizzo. Ollama non è una soluzione “magica” ma un componente di un sistema più ampio.

Casi d’uso tipici in una PMI

• Supporto interno IT / helpdesk: risposte su procedure, manuali, configurazioni standard, policy di sicurezza.
• Area Qualità: ricerca in norme interne, istruzioni operative, modulistica, audit precedenti.
• HR: policy, regolamenti, FAQ interne, percorsi di onboarding.
• Ufficio tecnico / progettazione: specifiche tecniche, manuali di macchinari, note applicative, casi risolti.

In tutti questi scenari il knowledge bot non sostituisce le persone, ma riduce il tempo speso a cercare informazioni, a rispondere sempre alle stesse domande e a navigare repository disordinati.

Se ti interessa il tema AI in locale per PMI, puoi approfondire anche l’articolo Ollama in locale per PMI: come proteggere i dati aziendali e ridurre i costi SaaS AI, dove affronto in dettaglio pro e contro rispetto ai servizi cloud.

Perché on‑prem (o almeno on‑private-cloud)

Per una PMI italiana, i motivi principali per tenere il knowledge bot vicino ai dati sono:

• GDPR e compliance: evitare che documenti sensibili (contratti, dati clienti, informazioni tecniche) escano dall’infrastruttura controllata.
• Controllo dei costi: con un carico prevedibile, un server dedicato con Ollama può costare meno di licenze SaaS per decine di utenti.
• Integrazione: accesso diretto a file server, SharePoint on‑prem, gestionali interni, senza passare da connettori cloud.
• Personalizzazione: possibilità di cambiare modello, pipeline di RAG, logica di autorizzazione senza vincoli di piattaforma.

Se invece stai lavorando in un ecosistema Microsoft 365, può avere senso valutare anche Copilot e Power Platform: in Guida completa a SharePoint, Power Platform e Copilot per PMI trovi una panoramica di governance e integrazioni.

Architettura di riferimento: come si costruisce un knowledge bot con Ollama

Vediamo ora un’architettura concreta, pensata per una PMI con 50–200 utenti interni, qualche server on‑prem o un piccolo cluster virtualizzato, e un team IT di 1–3 persone.

Componenti principali

Una possibile architettura logica include:

• Layer LLM: Ollama installato su un server Linux (o VM) con GPU dedicata o CPU potente.
• Layer RAG / orchestrazione: un servizio applicativo (es. Python con FastAPI o Node.js) che gestisce:
• embedding dei documenti
• ricerca vettoriale
• prompting strutturato verso Ollama
• policy di sicurezza e filtri
• Vector store: database per gli embedding (es. PostgreSQL + pgvector, Qdrant, ChromaDB).
• Ingestion pipeline: servizi schedulati che leggono da file server, SharePoint, gestionali, CRM e aggiornano l’indice.
• Interfaccia utente: web app interna (React/Vue/Blazor), integrazione in Teams, o semplice chat web.
• Monitoring & logging: log centralizzati delle richieste, metriche di utilizzo, alert.

Flusso di una richiesta

Il flusso tipico di una domanda al knowledge bot è:

1. L’utente apre la chat interna e pone una domanda (es. “Come registro una nuova non conformità cliente?”).
2. Il backend applicativo:
• identifica l’utente (SSO / AD / Azure AD)
• estrae embedding della domanda
• interroga il vector store per trovare i documenti più rilevanti
• applica filtri di autorizzazione (es. HR non vede documenti Qualità riservati)
3. Costruisce un prompt strutturato per Ollama, includendo:
• istruzioni di sistema (ruolo, stile, limiti)
• contesto (estratti dei documenti trovati)
• domanda dell’utente
4. Invia la richiesta a Ollama via API locale.
5. Riceve la risposta, la post‑processa (es. aggiunge link ai documenti originali) e la restituisce all’utente.

Scelta del modello e requisiti hardware

Uno dei vantaggi di Ollama è la possibilità di cambiare modello con un comando, ma per una PMI è importante scegliere qualcosa di stabile e sostenibile nel tempo.

Modelli tipici per knowledge bot interni

Per un knowledge bot aziendale, i requisiti principali sono:

• buona comprensione dell’italiano
• capacità di seguire istruzioni
• risposte sintetiche ma precise
• consumo di risorse compatibile con l’hardware disponibile

Alcuni modelli che, al momento della scrittura, hanno un buon rapporto qualità/risorse:

• LLaMA / LLaMA‑derivati 8B–13B: buoni per server con GPU media o CPU robuste.
• Mixtral / Mistral‑based: spesso efficienti e con buona qualità linguistica.
• Modelli specializzati per istruzioni (“Instruct”): utili per seguire policy aziendali.

La scelta va sempre validata con un set di prompt reali della tua azienda, non solo con benchmark generici.

Hardware minimo realistico per una PMI

Per un primo progetto pilota con 20–50 utenti potenziali:

• Server dedicato (fisico o VM): 16–32 GB RAM, CPU moderna (8+ core), SSD NVMe.
• GPU (opzionale ma consigliata): 12–24 GB VRAM se vuoi modelli più grandi e latenze basse.
• Storage: dipende dalla dimensione della knowledge base e dagli embedding (anche 200–500 GB possono bastare all’inizio).

Per progetti più strutturati, con più agenti AI e automazioni, è utile ragionare su un’architettura più ampia: ne parlo in Dai Prototipi alla Produzione: I Costi Nascosti degli AI Agent in Azienda.

Ingestion e aggiornamento della knowledge base aziendale

Il cuore di un knowledge bot non è il modello, ma la qualità della knowledge base aziendale e di come viene indicizzata.

Da dove arrivano i documenti

In una PMI tipica, le fonti principali sono:

• file server (cartelle condivise, PDF, Word, Excel)
• SharePoint / OneDrive
• gestionale / ERP (esportazioni di report, listini, anagrafiche)
• CRM (note clienti, offerte, ticket)
• wiki interni, strumenti di ticketing, sistemi qualità

La pipeline di ingestion deve:

• estrarre il testo (OCR se necessario)
• segmentare i documenti in chunk logici (es. 500–1500 caratteri)
• calcolare gli embedding
• salvare nel vector store con metadati (percorso, permessi, versione, data)

Gestione degli aggiornamenti

Due errori comuni:

• indicizzare tutto una volta e dimenticarsene
• reindicizzare tutto ogni notte, sovraccaricando server e rete

Una strategia più sana prevede:

• change detection: indicizzare solo file nuovi o modificati (timestamp, hash)
• versioning: mantenere traccia delle versioni dei documenti critici
• job schedulati: es. ingestion incrementale ogni notte, full reindex mensile
• monitoring: log di quanti documenti vengono aggiornati, errori di parsing, ecc.

Sicurezza, permessi e logging: non sono optional

Un knowledge bot interno che ignora i permessi è un rischio enorme: basta una domanda per far emergere documenti HR o contratti riservati a chi non dovrebbe vederli.

Allineare il bot ai permessi esistenti

Idealmente, il knowledge bot deve rispettare gli stessi permessi di:

• Active Directory / Azure AD
• permessi su SharePoint / file server
• ruoli applicativi (es. ruoli nel gestionale)

Questo significa che nella pipeline di ingestion e nel vector store devi salvare anche:

• gli ACL (Access Control List) o i gruppi autorizzati per ogni documento
• eventuali tag di classificazione (es. “HR”, “Qualità”, “Direzione”)

Al momento della query, il backend deve filtrare i risultati in base all’identità dell’utente, prima di costruire il prompt per Ollama.

Logging e audit

Per motivi di sicurezza, miglioramento continuo e anche per gestire eventuali contestazioni, è importante loggare:

• chi ha chiesto cosa (user id, timestamp)
• quali documenti sono stati usati come contesto
• la risposta generata (almeno per un certo periodo)
• eventuali errori o time‑out

Questi log devono essere protetti e accessibili solo a figure autorizzate (es. IT, DPO, responsabile Qualità), nel rispetto del GDPR.

Esperienza utente: se la UX è scarsa, il bot non verrà usato

Dal punto di vista tecnico è facile concentrarsi su modelli, embedding e architettura. Ma l’adozione in azienda dipende molto da come il knowledge bot viene presentato agli utenti.

Pattern di UX efficaci

• Chat con suggerimenti: mostrare esempi di domande utili per ogni area (IT, HR, Qualità, ecc.).
• Risposte con fonti: ogni risposta dovrebbe includere link ai documenti usati, così l’utente può verificare.
• Feedback loop: pulsanti “utile / non utile” e campo per commenti, per migliorare il sistema.
• Integrazione dove lavorano le persone: ad esempio, un bot in Teams o un pannello integrato nell’intranet.

Onboarding e change management

Per evitare che il bot venga percepito come un giocattolo o, peggio, come una minaccia, è utile:

• coinvolgere da subito alcuni power user (es. referenti di reparto) nella fase pilota
• definire chiaramente cosa il bot può e cosa non può fare
• fare brevi sessioni di formazione pratica (30–60 minuti) per mostrare casi d’uso reali
• comunicare che il bot non sostituisce nessuno, ma riduce attività ripetitive e a basso valore

Costi, tempi e rischi: cosa aspettarsi in una PMI

Un knowledge bot interno con Ollama non è un side‑project da weekend, ma nemmeno un progetto enterprise da centinaia di migliaia di euro. Per una PMI, il punto è trovare il giusto equilibrio tra ambizione e sostenibilità.

Ordini di grandezza

Indicativamente, per un primo progetto pilota con:

• 1–2 casi d’uso chiari (es. Qualità + IT)
• integrazione con una o due fonti (file server + SharePoint)
• interfaccia web semplice

puoi aspettarti:

• Setup iniziale: 4–8 settimane, a seconda della complessità delle integrazioni e della pulizia dei dati.
• Costi infrastrutturali: server dedicato o VM, eventuale GPU, storage per documenti e embedding.
• Manutenzione: aggiornamenti di sicurezza, monitoraggio, miglioramento continuo dei prompt e della pipeline di ingestion.

Se vuoi una panoramica più ampia su come valutare i costi nascosti di progetti AI in azienda, ti rimando ancora a Dai Prototipi alla Produzione: I Costi Nascosti degli AI Agent in Azienda.

Rischi principali da gestire

• Shadow IT: team che continuano a usare tool esterni non autorizzati perché il bot interno non è pronto o non funziona bene.
• Data leakage interno: esposizione di documenti sensibili a chi non dovrebbe vederli, per mancanza di filtri sui permessi.
• Progetto mai finito: ambito troppo ampio, mancanza di sponsor interni, obiettivi poco chiari.
• Over‑engineering: architetture troppo complesse rispetto alle reali esigenze della PMI.

Come partire in modo pragmatico

Per molte PMI italiane, l’approccio più sano è:

1. Definire 1–2 casi d’uso chiari (es. ridurre del 30% le richieste ripetitive all’IT, velocizzare la ricerca di procedure Qualità).
2. Mappare le fonti dati e fare una prima pulizia (duplicati, documenti obsoleti, permessi incoerenti).
3. Progettare una piccola architettura con Ollama, vector store e un’interfaccia semplice.
4. Lanciare un pilota controllato con un gruppo ristretto di utenti.
5. Misurare (tempo risparmiato, numero di richieste, feedback) e poi decidere come scalare.

Se non hai un team interno con esperienza specifica su AI in locale, RAG e integrazioni, ha senso farti affiancare da qualcuno che abbia già affrontato questi problemi in altre PMI, per evitare errori costosi su architettura, sicurezza e governance.

Quando ha senso chiedere supporto esterno

Un knowledge bot interno tocca contemporaneamente infrastruttura, sicurezza, processi e UX. Se:

• hai dati sensibili (clienti, fornitori, HR, proprietà intellettuale)
• non hai tempo per sperimentare per mesi
• vuoi un progetto che arrivi in produzione, non solo un POC

può essere utile lavorare con qualcuno che conosce sia il mondo AI in locale sia le esigenze concrete delle PMI italiane.

Se vuoi valutare un progetto di knowledge bot interno con Ollama, integrato con i tuoi sistemi e con una governance dati solida, possiamo partire da una call tecnica per analizzare stack, vincoli e priorità e definire un percorso realistico. Trovi tutti i dettagli sul servizio Sviluppo software su misura: trasformo esigenze operative in soluzioni solide e scalabili.