AI locale in produzione

Guida: Intelligenza Artificiale Locale › Produzione e sicurezza

Un prototipo AI che risponde sul PC dello sviluppatore non è ancora un servizio pronto per utenti o clienti. La messa in produzione richiede autenticazione, autorizzazioni, TLS, limitazione delle richieste, monitoraggio e backup, oltre alla gestione delle versioni dei modelli. Le API locali non devono essere pubblicate direttamente su Internet senza uno strato applicativo che applichi regole precise di accesso e protezione dei dati.

API e integrazione: collegare l’assistente al mondo

Prima di collegare un modello al sito o a un gestionale definisci chi può usarlo, quali documenti può interrogare, quali azioni può compiere e quali log conserverai. Un reverse proxy e un backend applicativo possono gestire autenticazione e limiti, ma servono anche controllo degli output, protezione dai prompt injection e un percorso di arresto in caso di comportamenti inattesi. Per i dati personali verifica anche ruoli e tempi di conservazione.

Il cuore: l’API compatibile con OpenAI

Ollama espone un’interfaccia compatibile con le API di OpenAI sulla porta 11434. Questo è ciò che rende l’integrazione semplice: qualunque strumento, libreria o codice pensato per OpenAI può parlare con il tuo Ollama cambiando solo l’indirizzo di destinazione. Una richiesta concettuale, mostrata con un comando da terminale per capirne la forma:

curl http://localhost:11434/api/chat -d '{
  "model": "assistente-bottega",
  "messages": [
    { "role": "user", "content": "Riparate i computer portatili?" }
  ],
  "stream": false
}'

Il sito, o un piccolo programma intermedio, fa esattamente questo: invia la domanda dell’utente, riceve la risposta del modello, la mostra nel riquadro della chat. C’è anche la modalità “streaming” ("stream": true), che invia la risposta parola per parola mentre viene generata, per l’effetto “sta scrivendo” tipico delle chat moderne, più piacevole per l’utente.

Usarlo da qualunque linguaggio

Poiché l’API è compatibile con OpenAI, puoi usare le librerie ufficiali di OpenAI in qualunque linguaggio (Python, JavaScript, PHP, ecc.) semplicemente puntandole al tuo server invece che a quello di OpenAI. Questo significa che tutto l’ecosistema di strumenti e tutorial pensati per OpenAI funziona con la tua AI locale, gratis e in casa. È uno dei motivi per cui Ollama ha vinto: non ti costringe a imparare nulla di esotico.

Integrare l’assistente nel sito (WordPress e oltre)

Per un chatbot sul sito, lo schema corretto non è mettere il modello dentro il sito, che lo appesantirebbe e non è il suo posto. Lo schema giusto è a tre livelli: il modello gira sulla sua macchina dedicata (la workstation o il server AI) ed espone l’API; un livello intermedio (un piccolo gestore lato server) fa da tramite, ed è dove metti i controlli; il sito, quando l’utente scrive, manda la domanda al livello intermedio, che la inoltra al modello e restituisce la risposta. Il sito resta leggero, il modello sta sul ferro giusto, e tra i due c’è uno strato che protegge e controlla.

Perché il livello intermedio è essenziale

Non far parlare mai il sito direttamente con il modello esposto su internet. Il livello intermedio (puoi realizzarlo in PHP sullo stesso server di WordPress, o come piccolo servizio separato) è dove metti l’autenticazione (solo le richieste legittime passano), i limiti di frequenza (nessuno può martellare il sistema), i filtri (sui contenuti in entrata e in uscita), e la logica (quale modello usare, quale prompt di sistema, quale RAG). È il guardiano tra il mondo e il tuo modello.

Lo schema per WordPress

Su WordPress, tieni separati i ruoli. Il contenuto e l’interfaccia stanno nel sito: un riquadro di chat realizzato con un blocco dedicato (per chi ha già blocchi personalizzati nel proprio editor a blocchi, è naturale costruirne uno che ospita la chat) o un piccolo script. Il dialogo con il modello passa per un endpoint lato server (in WordPress, una rotta delle API REST del sito, o un gestore AJAX) che fa da livello intermedio: riceve la domanda dal riquadro di chat, applica i controlli, chiama l’API di Ollama sulla macchina AI, e restituisce la risposta al riquadro. Concettualmente: il blocco di chat nel browser invia la domanda all’endpoint del tuo sito; l’endpoint la inoltra in modo controllato all’API del modello; la risposta torna indietro per la stessa strada. Per chi sviluppa già componenti su misura per il proprio sito, questo si traduce in un blocco per l’interfaccia e un gestore (un piccolo plugin o una funzione) per il dialogo controllato con l’API. Il bello è che, una volta in piedi questo schema, puoi cambiare modello, aggiornare il prompt, aggiungere il RAG sui tuoi documenti, il tutto senza toccare il sito: la logica vive nel livello intermedio e nella macchina AI.

Sicurezza: questa parte non è opzionale

Qui serve chiarezza assoluta, perché è il punto dove si fanno i danni. Un sistema AI mal esposto è una porta aperta come qualunque altra, e proprio perché sembra “un giocattolo” è facile abbassare la guardia. Non farlo.

La regola fondamentale

Non esporre mai l’endpoint di Ollama direttamente su internet senza protezione. L’API, di base, non ha autenticazione: chiunque la raggiunga può usare il tuo modello, consumare le tue risorse, e in scenari peggiori sondare il sistema. Va trattata come un servizio interno da proteggere con cura, esattamente come faresti con un database.

Le difese, a strati

Isola l’endpoint. Tieni Ollama accessibile solo dalla rete locale o dal livello intermedio fidato, mai aperto al mondo. Di base ascolta solo in locale; se devi renderlo raggiungibile da altre macchine, fallo sulla rete interna e chiudi tutto il resto con il firewall (su Linux, strumenti come ufw o regole iptables per esporre solo le porte necessarie alle sole sorgenti autorizzate).

Frapponi sempre un reverse proxy. Se il sito su internet deve raggiungere il modello, metti davanti un reverse proxy (nginx o Caddy) che gestisce l’accesso, applica HTTPS e fa da punto di controllo unico. Concettualmente, il proxy riceve le richieste dall’esterno su HTTPS, verifica che siano legittime, e le inoltra al servizio interno; il servizio non è mai esposto direttamente. Con Caddy l’HTTPS automatico (certificati Let’s Encrypt gratuiti e rinnovati da soli) è quasi a costo zero di configurazione; con nginx hai più controllo. In entrambi i casi, il principio è: il mondo parla solo con il proxy, mai con Ollama.

Autentica ogni richiesta. Il livello intermedio deve verificare una chiave segreta (non indovinabile, lunga, ruotabile) su ogni richiesta che arriva dal sito, così nessun estraneo può usare il tuo endpoint anche se ne scopre l’indirizzo.

Limita la frequenza. Applica rate limiting: un tetto di richieste per utente e per intervallo di tempo, così nessuno — né un attaccante né un bug — può martellare il sistema fino a metterlo in ginocchio. Si fa nel reverse proxy o nel livello intermedio.

Filtra gli input: la difesa dal prompt injection. Una minaccia specifica dei sistemi AI è il prompt injection: un utente malevolo che inserisce nella domanda istruzioni nascoste per manipolare il modello (“ignora le istruzioni precedenti e fai X”). Le difese: un prompt di sistema robusto che ribadisca i limiti, controlli sui contenuti in entrata e in uscita, e — soprattutto se l’assistente ha strumenti che agiscono — permessi rigorosi su cosa il modello può effettivamente fare. Un assistente che solo risponde è poco rischioso; uno che può scrivere su sistemi o mandare email va progettato con la mentalità “non fidarti mai dell’input”.

Cifra e segmenta. Tutto il traffico verso l’esterno passa per HTTPS. La macchina AI sta su un segmento di rete adeguato, raggiungibile solo da chi deve. Se ti serve accedere all’assistente da remoto (per esempio da fuori ufficio), fallo tramite VPN invece di esporre il servizio su internet: entri nella rete in modo cifrato e autenticato, e l’assistente resta interno.

Lo schema sicuro, in sintesi

Il disegno corretto è a strati: il modello e Ollama girano sulla macchina dedicata, isolati e non esposti; un livello intermedio fidato è l’unico che parla con Ollama, e si occupa di autenticazione, limiti e filtri; il sito parla solo con quel livello intermedio; tutto il traffico verso l’esterno passa per un reverse proxy con HTTPS; il firewall chiude tutto il resto; l’accesso remoto passa per VPN. Costruito così, hai un assistente potente e privato, senza aprire falle. Per chi ha competenze di rete e sicurezza, niente di tutto questo è esotico: sono le buone pratiche di qualunque servizio esposto, applicate con la stessa serietà.

Manutenzione e operazioni: tenere viva la macchina

Una volta in produzione, il sistema va mantenuto. Poco lavoro, se impostato bene, ma non zero.

Aggiornamenti. Tieni aggiornati Ollama (le versioni recenti aggiungono supporto hardware, velocità, modelli), Open WebUI, i container, e il sistema operativo con le patch di sicurezza. Con Docker, aggiornare è scaricare le nuove immagini e riavviare i container; con i volumi montati, i dati sopravvivono. Aggiorna i modelli quando escono versioni migliori, ma testa prima su un modello di prova che il comportamento resti quello atteso: un modello nuovo può comportarsi diversamente.

Backup. Salva ciò che conta: le configurazioni (i Modelfile, i file Docker Compose, le impostazioni del reverse proxy), i dati di Open WebUI (cronologie, utenti, documenti caricati per il RAG), e il database vettoriale del RAG. I modelli in sé non serve salvarli — si riscaricano — ma le configurazioni e i dati sì. Un backup regolare e testato ti permette di ricostruire tutto in fretta in caso di guasto.

Monitoraggio. Tieni d’occhio la salute della macchina: occupazione VRAM e temperatura della GPU (con nvidia-smi o strumenti grafici), carico e memoria di sistema, spazio su disco (i modelli e i log crescono), e disponibilità del servizio. Per un sistema serio, strumenti di monitoraggio (anche semplici) che ti avvisano se qualcosa va storto valgono il tempo di configurarli.

Log. Registra le richieste e gli errori, in modo da poter diagnosticare problemi e capire l’uso reale. Attenzione, però, alla privacy: se l’assistente tratta dati sensibili, i log delle conversazioni sono essi stessi dati sensibili, da proteggere e gestire secondo le stesse regole (e da non conservare oltre il necessario). Un log ben fatto è prezioso per il debug; un log mal protetto è una falla.

Capacità. Man mano che l’uso cresce, tieni d’occhio se la macchina regge: se i tempi di risposta si allungano sotto carico, o se servi più utenti del previsto, potrebbe servire ottimizzare (modello più leggero, contesto più corto, Ollama configurato per più parallelismo) o passare a un motore da throughput (vLLM) o a hardware superiore. Meglio accorgersene dai numeri che dalle lamentele degli utenti.

← RAG e personalizzazioneApplicazioni →