Privacy: what actually goes over the network when AI is local

The question that matters

You chose local AI because your data stays yours. But what actually leaves your computer when you talk to a model that runs locally? What prompts go out, where do they end up, who sees them?

This question has a precise answer, and the right answer is not "nothing" as a blanket statement: it's almost nothing, with a few exceptions you should check. The good news is that everything can be verified in half an hour, with the right tools.

The normal flow: your data never leaves the machine

When you chat with a local model, the data flow is simple. The text you type is converted into tokens, the tokens pass from the model weights into the memory of your GPU or RAM, and the response comes back to your interface. In this path, your prompt does not traverse the network. There is no inference server in a data center: the inference happens on your machine. That is what distinguishes local AI from cloud AI.

The official FAQ of one of the most used runtimes says it directly: when the model runs locally, the service does not see your prompts or your data. This holds for the main inference runtimes: Ollama, llama.cpp, LM Studio. Ollama runs the model in a local process and listens for network requests only on the localhost interface (127.0.0.1), so your apps can connect to it. Ollama's local server is built for your own computer: its networking guidance is mostly about how to expose it, if you want, to your local network.

What actually goes out over the network

The only times local AI touches the network are these:

The first model download. When you download a model from a registry (for example from Hugging Face through Ollama), gigabytes of data come to you. In that connection, however, there is no prompt from you: there is a file, with an address and a checksum.

Automatic checks. Ollama and LM Studio check whether a newer version of the software exists: on Mac and Windows, the app downloads updates automatically. These calls carry no content: they are automatic requests.

Optional network features. This is the delicate point. In Ollama, the web search is part of the "cloud features": if you enable it, the model's search queries leave toward an external service. An important detail: it works as a tool for the model — the prompt stays on your machine, but the query the model chooses to search for leaves over the network. That is not the same as a cloud chatbot, where all the text goes to the provider.

And here you have full control: Ollama can run in "local only" mode, with the cloud features switched off completely. You set disable_ollama_cloud: true in ~/.ollama/server.json (or the OLLAMA_NO_CLOUD=1 environment variable) and restart Ollama. In the logs you can verify that the cloud is disabled: from that moment, no query leaves over the network.

The key concept: telemetry vs data

This is where the most common trap lives. Telemetry is the data a program sends to say "what I did" — version, error type, usage metrics. Content data, on the other hand, is your actual information: your prompts, your documents, your files. A program can send telemetry without ever touching your data, and it can send nothing at all. The two are not automatically linked: the fact that a program sends no telemetry does not guarantee that your data is not going out through an optional feature, and vice versa.

That is why, when you read a privacy policy, the question to always ask is the same: what data goes out, and under what conditions? Not "is the program online, yes or no?".

Your access point: localhost

Everything that runs locally talks to everything else through localhost, the network interface of your own computer (127.0.0.1). Ollama listens there, LM Studio listens there, web UIs and applications connect there. This is why a well-configured firewall is the first defense tool: if the local interface is not reachable from outside, not even malware on your machine can "steal" your prompts by sending them to a remote server without you noticing. The firewall decides who may talk to whom — and that is exactly the question you should be asking.

How you verify it yourself: three tools

The good news is that you do not have to trust anyone: you can measure what goes out over the network yourself. Three tools, all free and open source.

tcpdump is the command-line tool: it captures the packets that pass through your network interface and shows them one by one. It is the most direct way to answer the question "who is talking to the outside?". You install it with your system's package manager and start it with a filter to see only outbound connections. The manual is short and clear: a few seconds to understand what is happening.

Wireshark is the graphical version: it captures traffic and displays it in a navigable panel, with filters, colors and statistics. It is the tool that lets you "see" the network. On a machine with your local setup, a filter such as tcp.port == 11434 shows you in real time the connections to the Ollama server. If the local traffic is only between your own programs and nothing is coming from outside, you have your answer.

mitmproxy is the most powerful of the three: it is a proxy that intercepts and displays the contents of HTTPS requests in plaintext. It is the right tool when you want to know not just who is talking to whom, but what they are saying. You put it between your system and the outside world, and every request passes through it: you see addresses, headers, bodies. To find out whether an app is sending your content to a remote endpoint, mitmproxy is the definitive tool.

The verification procedure, step by step

1. Start the capture. With tcpdump, Wireshark or mitmproxy, record all outbound traffic from your machine.
2. Close everything else. Stop browsers, automatic updates, apps that make requests in the background: you want to isolate your AI setup.
3. Start the local model and have a short conversation, the way you normally would.
4. Look at the traffic. You should see system connections (DNS, NTP) but no connection carrying your text to a third-party domain.
5. Repeat with optional features turned on (for example web search) and compare: now you can see the queries leaving toward the search engines. That is exactly the behavior you would expect — and you saw it, rather than being told about it.

Once you have done this, you have verifiable knowledge of what leaves your local AI setup over the network. That is the difference between faith and control.

Common mistake: the app that "uses local AI" but sends everything to the cloud

A case that comes up again and again: an application that presents a model as "local AI" while the model actually runs on a remote server, or an app that sends your prompt to the vendor's API and returns it "from the local AI". The way to recognize it is always the same: observe the traffic. If your text is going out to a domain that is not yours, the model is not local — or at least, it is not really local for your data.

Verdict

Local AI, properly configured, does not send your content over the network. Your prompts stay on your machine, the model weights stay on your disk, and the only network communications are the ones you opted into, and can switch off in an instant.

But "properly configured" is not a given: it is a verification you do yourself, with the right tools, in half an hour. And once you have done it, you no longer have to trust a promise: you know what goes out, and you know why.

Sources

• Ollama official FAQ — docs.ollama.com/faq
• Ollama web search (optional network tool) — docs.ollama.com/capabilities/web-search
• tcpdump — official manual — www.tcpdump.org/manpages/tcpdump.1.html
• Wireshark — wireshark.org
• mitmproxy — mitmproxy.org

Article generated with AI