Privacy: cosa gira davvero in rete quando l'IA è locale

La domanda che conta

Hai scelto l'IA locale perché i tuoi dati restano tuoi. Ma cosa attraversa davvero il tuo computer quando scrivi a un modello che gira in locale? Che prompt partono, dove finiscono, chi li vede?

Questa domanda ha una risposta precisa, e la risposta giusta non è "niente" in blocco: è quasi niente, con qualche eccezione che va controllata. La buona notizia è che tutto si verifica in mezz'ora, con gli strumenti giusti.

Il flusso normale: i tuoi dati non lasciano la macchina

Quando chatti con un modello locale, il flusso dei dati è semplice. Il testo che scrivi viene convertito in token, i token passano dai pesi del modello alla memoria della GPU o della RAM, e la risposta torna sulla tua interfaccia. In questo percorso il tuo prompt non attraversa il network. Non c'è un server di inference in un data center: l'inference avviene sulla tua macchina. È questo che distingue l'IA locale dall'IA in cloud.

Il FAQ ufficiale di uno dei runtime più usati lo dice in modo diretto: quando il modello gira in locale, il servizio non vede i tuoi prompt né i tuoi dati. Questo vale per i runtime principali: Ollama, llama.cpp, LM Studio. Ollama esegue il modello in un processo locale e ascolta richieste in rete soltanto sull'interfaccia di localhost (127.0.0.1), così le tue app possono collegarvisi. Il server locale di Ollama è pensato per il tuo computer: le istruzioni di rete riguardano soprattutto come esporlo, se vuoi, in rete domestica.

Cosa parte davvero in rete

Le uniche volte in cui l'IA locale tocca il network sono queste:

Il primo download del modello. Quando scarichi un modello dal registro (per esempio da Hugging Face tramite Ollama), arrivano sui gigabyte di dati verso di te. In quella connessione però non c'è il tuo prompt: c'è un file, con un indirizzo e una somma di verifica.

Le verifiche automatiche. Ollama e LM Studio controllano se esiste una nuova versione del software: su Mac e Windows l'app scarica gli aggiornamenti in automatico. Queste chiamate non portano contenuti: sono richieste automatiche.

Le funzioni opzionali di rete. Il punto delicato. In Ollama, la web search fa parte dei "cloud features": se la attivi, le query di ricerca del modello partono verso un servizio esterno. Un dettaglio importante: funziona come un tool del modello — il tuo prompt resta nella tua macchina, ma la query che il modello sceglie di cercare parte in rete. Non è la stessa cosa di un chatbot in cloud, dove tutto il testo va al provider.

E qui hai il controllo completo: Ollama si mette in modalità "solo locale", con i cloud features disattivati del tutto. Imposti disable_ollama_cloud: true in ~/.ollama/server.json (oppure la variabile d'ambiente OLLAMA_NO_CLOUD=1) e riavvii Ollama. Nei log puoi verificare che il cloud sia disattivato: da quel momento nessuna query parte in rete.

Il concetto chiave: telemetria vs dati

Qui sta la trappola più comune. Telemetria sono i dati che il software invia per dire "cos'ho fatto" — versione, tipo di errore, metriche di utilizzo. Dati dei contenuti sono invece le tue informazioni: i prompt, i documenti, i file. Un software può inviare telemetria senza mai toccare i tuoi dati, e può non inviare nulla. Le due cose non sono automaticamente legate: il fatto che un programma non invii telemetria non garantisce che i tuoi dati non partano attraverso una funzione opzionale, e viceversa.

Per questo, quando leggi una policy di privacy, la domanda da fare è sempre la stessa: quali dati partono, e in quali condizioni? Non "il programma è online sì o no?".

Il tuo punto di accesso: localhost

Tutto ciò che gira in locale si connette tra sé e sé attraverso il localhost, l'interfaccia di rete del tuo stesso computer (127.0.0.1). Ollama ascolta lì, LM Studio ascolta lì, WebUI e applicazioni si collegano lì. Questo è il motivo per cui un firewall ben configurato è il primo strumento di difesa: se l'interfaccia locale non è raggiungibile dall'esterno, nemmeno un malware sul tuo computer può "rubare" i tuoi prompt facendoli partire verso un server remoto senza che lo noti. Il firewall dice chi può parlare con chi — ed è proprio questa la domanda che ti devi fare.

Come verifichi da solo: tre strumenti

La buona notizia è che non devi fidarti di nessuno: puoi misurare tu stesso ciò che parte in rete. Tre strumenti, tutti gratuiti e open source.

tcpdump è lo strumento da riga di comando: cattura i pacchetti che passano sulla tua interfaccia di rete e li mostra uno per uno. È la via più diretta per rispondere alla domanda "chi sta parlando con l'esterno?". Lo installi con il gestore pacchetti del tuo sistema e lo avvii con un filtro per vedere solo le connessioni in uscita. Il manuale è breve e chiaro: pochi secondi per capire cosa sta succedendo.

Wireshark è la versione con interfaccia grafica: cattura il traffico e lo mostra in un pannello navigabile, con filtri, colori e statistiche. È lo strumento che ti fa "vedere" la rete. Su una macchina con il tuo setup locale, un filtro come tcp.port == 11434 ti mostra in tempo reale le connessioni al server di Ollama. Se il traffico locale va e viene tra i tuoi programmi e non arriva da fuori, hai la tua risposta.

mitmproxy è il più potente dei tre: è un proxy che intercetta e mostra i contenuti delle richieste HTTPS in chiaro. È lo strumento giusto quando vuoi sapere non solo chi parla con chi, ma cosa dicono. Lo metti tra il tuo sistema e l'esterno e ogni richiesta passa da lui: vedi indirizzi, intestazioni, testi. Per capire se un'app invia o meno i tuoi contenuti a un endpoint remoto, mitmproxy è lo strumento definitivo.

La procedura di verifica, passo per passo

1. Avvia la cattura. Con tcpdump, Wireshark o mitmproxy, registra tutto il traffico in uscita della tua macchina.
2. Chiudi tutto il resto. Ferma browser, aggiornamenti automatici, app che fanno richieste in background: vuoi isolare il tuo setup di IA.
3. Avvia il modello in locale e fai una conversazione breve, come faresti normalmente.
4. Guarda il traffico. Dovresti vedere connessioni di sistema (DNS, NTP) ma nessuna connessione che porta il tuo testo verso un dominio di terze parti.
5. Ripeti con le funzioni opzionali attive (per esempio la web search) e confronta: adesso vedi le query partire verso i motori di ricerca. È esattamente il comportamento che ti aspetteresti — e lo hai visto, non te l'hanno raccontato.

Fatto questo, hai una conoscenza verificabile di cosa parte in rete dal tuo setup di IA locale. È questa la differenza tra la fede e il controllo.

Errore comune: l'app che "usa l'IA locale" ma manda tutto in cloud

Un caso che torna spesso: un'applicazione che presenta come "IA locale" un modello che in realtà gira su un server remoto, oppure un'app che manda il tuo prompt a un'API dell'editore e lo ritorna "dall'IA locale". Il modo di riconoscerlo è sempre lo stesso: osservare il traffico. Se il tuo testo parte verso un dominio che non è il tuo, il modello non è locale — o almeno, non lo è davvero per i tuoi dati.

Verdetto

L'IA locale, configurata bene, non invia i tuoi contenuti in rete. I tuoi prompt restano sulla tua macchina, i pesi del modello restano sul tuo disco, e le uniche comunicazioni in rete sono quelle che hai attivato tu e che puoi disattivare in un istante.

Ma "configurata bene" non è un dato di fatto: è una verifica che fai tu, con gli strumenti giusti, in mezz'ora. E una volta che l'hai fatta, non devi più fidarti di una promessa: sai quello che parte, e sai perché.

Fonti

• FAQ ufficiale di Ollama — docs.ollama.com/faq
• Web search di Ollama (tool di rete opzionale) — docs.ollama.com/capabilities/web-search
• tcpdump — manuale ufficiale — www.tcpdump.org/manpages/tcpdump.1.html
• Wireshark — wireshark.org
• mitmproxy — mitmproxy.org

Articolo generato con IA